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Preface 


The exponential growth of mobile devices has revolutionized many aspects of our lives. In 
what is called as the post-PC era, smartphones are engulfing desktop computers with their 
enhanced functionality and improved storage capacity. This rapid transformation has led to 
increased usage of mobile handsets across all the sectors. 

Despite their small size, smartphones are capable of performing many tasks: sending 
private messages and confidential e-mails, taking photos and videos, making online 
purchases, viewing our salary slips, completing banking transactions, accessing social 
networking sites, managing business tasks, and more. Hence, a mobile device is now a huge 
repository of sensitive data that can provide a wealth of information about its owner. This 
has in turn led to the evolution of Mobile Device Forensics, a branch of digital forensics that 
deals with retrieving data from a mobile device. Today, there is huge demand for 
specialized forensic experts, especially given the fact that the data retrieved from a mobile 
device is court admissible. 

Mobile forensics is all about utilizing scientific methodologies to recover data stored within 
a mobile phone for legal purposes. Unlike traditional computer forensics, mobile forensics 
has limitations in obtaining evidence due to rapid changes in the technology and the fast- 
paced evolution of mobile software. With different operating systems and with a wide 
range of models being released into the market, mobile forensics has expanded over the last 
few years. Specialized forensic techniques and skills are required in order to extract data 
under different conditions. 

This book takes you through the challenges involved in mobile forensics and practically 
explains detailed methods of collecting evidence from different mobile devices with iOS, 
Android, and Windows mobile operating systems. 

This book is organized in a manner that allows you to focus independently on chapters that 
are specific to your required platform. 
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What this book covers 

Chapter 1 , Introduction to Mobile Forensics, introduces you to the concepts of mobile 
forensics, its core values, and its limitations. This chapter also provides an overview of 
practical approaches and best practices involved in performing mobile forensics. 

Chapter 2, Understanding the Internals ofiOS Devices, provides an overview of the popular 
Apple iOS devices, including an outline of different models and their hardware. 

Throughout this book, we explain iOS security features and device security and its impact 
on the iOS forensics approaches. This chapter also gives an overview of the iOS file system 
and outlines the sensitive files that are useful for forensic examination. 

Chapter 3, iOS Forensic Tools, gives an overview of existing open source and commercial 
iOS forensics tools. These tools differ in the range of mobile phones they support and the 
amount of data that they can recover. This chapter describes the advantages and limitations 
of those tools 

Chapter 4, Data Acquisition from iOS Devices, covers various types of forensic acquisition 
methods that can be performed on iOS devices and guides you through preparing your 
desktop machine for forensic work. This chapter also discusses passcode bypass techniques 
and physical extraction of the devices and explains different ways in which the device can 
be imaged. 

Chapter 5, Data Acquisition from iOS Backups, provides detailed explanations of different 
types of iOS backup and details what types of file are stored in the backup. This chapter 
also covers logical acquisition techniques of recovering data from the backups. 

Chapter 6, iOS Data Analysis and Recovery, discusses the types of data that is stored on iOS 
devices and the general location of this data storage. Common file types used in iOS devices 
such as plist and SQLite are discussed in detail to provide an understanding of how the 
data is being stored on the device, which will help the forensic examiners to efficiently 
recover data from these files. 

Chapter 7, Understanding Android, introduces you to the Android model, file system, and 
its security features. It provides an explanation of how data is stored in any Android device, 
which will be useful while carrying out forensic investigation. 

Chapter 8, Android Forensic Setup and Pre Data Extraction Techniques, guides you through 
the Android forensic setup and other techniques to follow before extracting any 
information. Screen lock bypass techniques and gaining root access are also discussed in 
this chapter. 
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Chapter 9, Android Data Extraction Techniques, provides an explanation of physical, file 
system, and logical acquisition techniques for extracting relevant information from an 
Android device. 

Chapter 10, Android Data Analysis and Recovery, talks about extracting and analyzing data 
from Anroid image files. This chapter also covers possibilities and limitations for recovering 
deleted data from Android devices. 

Chapter 1 1 , Android App Analysis, Malware, and Reverse Engineering, covers the analysis of 
some of the widely used Android apps to retrieve valuable data. This chapter also covers 
Android malware and techniques to reverse engineer an Android app. 

Chapter 12, Windows Phone Forensics, provides a basic overview of forensic approaches 
when dealing with Windows Phones. 

Chapter 13, Parsing Third-Party Application Files, covers forensic approaches to include 
acquisition and analysis techniques when dealing with BlackBerry devices. BlackBerry 
encryption and data protection is also addressed. 

What you need for this book 

This book provides practical forensic approaches and explains the techniques in a simple 
manner. The content is organized in a way that allows even a user with basic computer 
skills to examine the device and extract the required data. A Macintosh, Windows, or Linux 
computer will be helpful to successfully repeat the methods defined in this book. Where 
possible, methods for all computer platforms are provided. 

Who this book is for 

This book is intended for forensic examiners with little or basic experience in mobile 
forensics or with open source solutions for mobile forensics. This book will also be useful to 
computer security professionals, researchers, and anyone seeking a deeper understanding 
of mobile internals. This book will also come in handy for those who are trying to recover 
accidentally deleted data (photos, contacts, SMS, and more.). 

Conventions 

In this book, you will find a number of styles of text that distinguish between different 
kinds of information. Here are some examples of these styles, and an explanation of their 
meaning. 
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Code words in text are shown as follows: "The user data partition occupies most of the 
NAND memory and is mounted at /private/var on the device." 

Any command-line input or output is written as follows: 

$ git clone https://github.com/benvium/libimobiledevice-macosx.git 
-/Desktop/libimobiledevice-macosx/ 

New terms and important words are shown in bold. Words that you see on the screen, in 
menus or dialog boxes for example, appear in the text like this: "Every time an application is 
suspended to the background by pressing the Home button". 


o 

0 


Warnings or important notes appear in a box like this. 


Tips and tricks appear like this. 


Reader feedback 

Feedback from our readers is always welcome. Let us know what you think about this 
book— what you liked or disliked. Reader feedback is important for us as it helps us 
develop titles that you will really get the most out of. 

To send us general feedback, simply e-mail feedback@packtpub . com, and mention the 
book's title in the subject of your message. 

If there is a topic that you have expertise in and you are interested in either writing or 
contributing to a book, see our author guide at www . packtpub . com/ authors. 

Customer support 

Now that you are the proud owner of a Packt book, we have a number of things to help you 
to get the most from your purchase. 
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Errata 

Although we have taken every care to ensure the accuracy of our content, mistakes do 
happen. If you find a mistake in one of our books— maybe a mistake in the text or the 
code— we would be grateful if you could report this to us. By doing so, you can save other 
readers from frustration and help us improve subsequent versions of this book. If you find 
any errata, please report them by visiting http : //www.packtpub . com/submit-errata, 
selecting your book, clicking on the Errata Submission Form link, and entering the details 
of your errata. Once your errata are verified, your submission will be accepted and the 
errata will be uploaded to our website or added to any list of existing errata under the 
Errata section of that title. 

To view the previously submitted errata, go to https : //www . packtpub . com/books/con 
tent /support and enter the name of the book in the search field. The required information 
will appear under the Errata section. 

Piracy 

Piracy of copyrighted material on the Internet is an ongoing problem across all media. At 
Packt, we take the protection of our copyright and licenses very seriously. If you come 
across any illegal copies of our works in any form on the Internet, please provide us with 
the location address or website name immediately so that we can pursue a remedy. 

Please contact us at copyright@packtpub . com with a link to the suspected pirated 
material. 

We appreciate your help in protecting our authors and our ability to bring you valuable 
content. 


Questions 

If you have a problem with any aspect of this book, you can contact us 
at quest ions @packtpub . com, and we will do our best to address the problem. 
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Introduction to Mobile Forensics 

There is no doubt that mobile devices have become part of our lives and revolutionized the 
way we do most of our activities. As a result, a mobile device is now a huge repository that 
holds sensitive information about its owner. This has in turn led to the rise of mobile device 
forensics, a branch of digital forensics that deals with retrieving data from a mobile device. 
This book will help you understand forensic techniques on three main platforms — Android, 
iOS, and Windows. We will practically go through various methods that can be followed to 
collect evidence from different mobile devices. 

In this chapter, we will cover the following topics: 

• Introduction to mobile forensics 

• Challenges in mobile forensics 

• Mobile phone evidence extraction process 

• Mobile forensic approaches 

• Good forensic practices 


Why do we need mobile forensics? 

In 2015, there were more than 7 billion mobile cellular subscriptions worldwide, up from 
less than 1 billion in 2000, says International Telecommunication Union (ITU). The world 
is witnessing technology and user migration from desktops to mobile phones. The 
following graph sourced from statista . com shows the actual and estimated growth of 
smartphones from the year 2009 to 2018. 


Introduction to Mobile Forensics 


2,500 



2009 2010 2011 2012 2013 2014 2015 2016 “ 2017 * 2018 * 2019 * 


Growth of smartphones from 2009 to 2018 in million units 

Gartner Inc. reports that global mobile data traffic reached 52 million terabytes (TB) in 2015, 
an increase of 59 percent from 2014, and the rapid growth is set to continue through 2018, 
when mobile data levels are estimated to reach 173 million TB. Smartphones of today, such 
as the Apple iPhone, the Samsung Galaxy series, and BlackBerry phones, are compact forms 
of computers with high performance, huge storage, and enhanced functionalities. Mobile 
phones are the most personal electronic device that a user accesses. They are used to 
perform simple communication tasks, such as calling and texting, while still providing 
support for Internet browsing, e-mail, taking photos and videos, creating and storing 
documents, identifying locations with GPS services, and managing business tasks. As new 
features and applications are incorporated into mobile phones, the amount of information 
stored on the devices is continuously growing. Mobiles phones become portable data 
carriers, and they keep track of all your movements. With the increasing prevalence of 
mobile phones in peoples' daily lives and in crime, data acquired from phones become an 
invaluable source of evidence for investigations relating to criminal, civil, and even high- 
profile cases. It is rare to conduct a digital forensic investigation that does not include a 
phone. Mobile device call logs and GPS data were used to help solve the attempted 
bombing in Times Square, New York, in 2010. 
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The details of the case can be found at http : //www . forensicon . com/ f orensics-blott 
er/ cell-phone-email-f orensics-investigation-cracks-nyc- times -square-car 
-bombing-case/. 

The science behind recovering digital evidence from mobile phones is called mobile 
forensics. Digital evidence is defined as information and data that is stored on, received, or 
transmitted by an electronic device that is used for investigations. Digital evidence 
encompasses any and all digital data that can be used as evidence in a case. 


Mobile forensics 

Digital forensics is a branch of forensic science focusing on the recovery and investigation 
of raw data residing in electronic or digital devices. The goal of the process is to extract and 
recover any information from a digital device without altering the data present on the 
device. Over the years, digital forensics has grown along with the rapid growth of 
computers and various other digital devices. There are various branches of digital forensics 
based on the type of digital device involved such as computer forensics, network forensics, 
mobile forensics, and so on. 

Mobile forensics is a branch of digital forensics related to the recovery of digital evidence 
from mobile devices. Forensically sound is a term used extensively in the digital forensics 
community to qualify and justify the use of particular a forensic technology or 
methodology. The main principle for a sound forensic examination of digital evidence is 
that the original evidence must not be modified. This is extremely difficult with mobile 
devices. Some forensic tools require a communication vector with the mobile device, thus a 
standard write protection will not work during forensic acquisition. Other forensic 
acquisition methods may involve removing a chip or installing a bootloader on the mobile 
device prior to extract data for forensic examination. In cases where the examination or data 
acquisition is not possible without changing the configuration of the device, the procedure 
and the changes must be tested, validated, and documented. Following proper 
methodology and guidelines is crucial in examining mobile devices as it yields the most 
valuable data. As with any evidence gathering, not following the proper procedure during 
the examination can result in loss or damage of evidence or render it inadmissible in court. 

The mobile forensics process is broken down into three main categories: 
seizure, acquisition, and /examination/analysis. Forensic examiners face some challenges 
while seizing the mobile device as a source of evidence. At the crime scene, if the mobile 
device is found switched off, the examiner should place the device in a faraday bag to 
prevent changes should the device automatically power on. As shown in the following 
figure, Faraday bags are specifically designed to isolate the phone from the network. 
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a Faraday bag (image courtesy: http : / / www . amazon . com/Black-Hole-Faraday-Bag- 1 solat ion/d 

p/B0091WILY0) 

If the phone is found switched on, switching it off has a lot of concerns attached to it. If the 
phone is locked by a PIN or password or encrypted, the examiner will be required to bypass 
the lock or determine the PIN to access the device. Mobile phones are networked devices 
and can send and receive data through different sources, such as telecommunication 
systems, Wi-Fi access points, and Bluetooth. So, if the phone is in a running state, a criminal 
can securely erase the data stored on the phone by executing a remote wipe command. 
When a phone is switched on, it should be placed in a faraday bag. If possible, prior to 
placing the mobile device in the faraday bag, disconnect it from the network to protect the 
evidence by enabling the flight mode and disabling all network connections (Wi-Fi, GPS, 
Hotspots, and so on). This will also preserve the battery, which will drain while in a faraday 
bag and protect against leaks in the faraday bag. Once the mobile device is seized properly, 
the examiner may need several forensic tools to acquire and analyze the data stored on the 
phone. 

Mobile device forensic acquisition can be performed using multiple methods, which are 
defined later. Each of these methods affects the amount of analysis required, which will be 
discussed in greater detail in the upcoming chapters. Should one method fail, another must 
be attempted. Multiple attempts and tools may be necessary in order to acquire the 
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maximum data from the mobile device. 

Mobile phones are dynamic systems that present a lot of challenges to the examiner in 
extracting and analyzing digital evidence. The rapid increase in the number of different 
kinds of mobile phones from different manufacturers makes it difficult to develop a single 
process or tool to examine all types of devices. Mobile phones are continuously evolving as 
existing technologies progress and new technologies are introduced. Furthermore, each 
mobile is designed with a variety of embedded operating systems. Hence, special 
knowledge and skills are required from forensic experts to acquire and analyze the devices. 


Challenges in mobile forensics 

One of the biggest forensic challenges when it comes to the mobile platform is the fact that 
data can be accessed, stored, and synchronized across multiple devices. As the data is 
volatile and can be quickly transformed or deleted remotely, more effort is required for the 
preservation of this data. Mobile forensics is different from computer forensics and presents 
unique challenges to forensic examiners. 

Law enforcement and forensic examiners often struggle to obtain digital evidence from 
mobile devices. The following are some of the reasons: 

• Hardware differences: The market is flooded with different models of mobile 
phones from different manufacturers. Forensic examiners may come across 
different types of mobile models, which differ in size, hardware, features, and 
operating system. Also, with a short product development cycle, new models 
emerge very frequently. As the mobile landscape is changing each passing day, it 
is critical for the examiner to adapt to all the challenges and remain updated on 
mobile device forensic techniques across various devices. 

• Mobile operating systems: Unlike personal computers where Windows has 
dominated the market for years, mobile devices widely use more operating 
systems, including Apple's iOS, Google's Android, RIM's BlackBerry OS, 
Microsoft's Windows Mobile, HP's webOS, Nokia's Symbian OS, and many 
others. Even within these operating systems, there are several versions which 
make the task of forensic investigator even more difficult. 

• Mobile platform security features: Modern mobile platforms contain built-in 
security features to protect user data and privacy. These features act as a hurdle 
during the forensic acquisition and examination. For example, modern mobile 
devices come with default encryption mechanisms from the hardware layer to the 
software layer. The examiner might need to break through these encryption 
mechanisms to extract data from the devices. 

• Lack of resources: As mentioned earlier, with the growing number of mobile 
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phones, the tools required by a forensic examiner would also increase. Forensic 
acquisition accessories, such as USB cables, batteries, and chargers for different 
mobile phones, have to be maintained in order to acquire those devices. 

• Preventing data modification: One of the fundamental rules in forensics is to 
make sure that data on the device is not modified. In other words, any attempt to 
extract data from the device should not alter the data present on that device. But 
this is practically not possible with mobiles because just switching on a device 
can change the data on that device. Even if a device appears to be in an off state, 
background processes may still run. For example, in most mobiles, the alarm 
clock still works even when the phone is switched off. A sudden transition from 
one state to another may result in the loss or modification of data. 

• Anti-forensic techniques: Anti-forensic techniques, such as data hiding, data 
obfuscation, data forgery, and secure wiping, make investigations on digital 
media more difficult. 

• Dynamic nature of evidence: Digital evidence may be easily altered either 
intentionally or unintentionally. For example, browsing an application on the 
phone might alter the data stored by that application on the device. 

• Accidental reset: Mobile phones provide features to reset everything. Resetting 
the device accidentally while examining may result in the loss of data. 

• Device alteration: The possible ways to alter devices may range from moving 
application data, renaming files, and modifying the manufacturer's operating 
system. In this case, the expertise of the suspect should be taken into account. 

• Passcode recovery: If the device is protected with a passcode, the forensic 
examiner needs to gain access to the device without damaging the data on the 
device. While there are techniques to bypass the screen lock, they may not always 
work on all the versions. 

• Communication shielding: Mobile devices communicate over cellular networks, 
Wi-Fi networks, Bluetooth, and Infrared. As device communication might alter 
the device data, the possibility of further communication should be eliminated 
after seizing the device. 

• Lack of availability of tools: There is a wide range of mobile devices. A single 
tool may not support all the devices or perform all the necessary functions, so a 
combination of tools needs to be used. Choosing the right tool for a particular 
phone might be difficult. 

• Malicious programs: The device might contain malicious software or malware, 
such as a virus or a Trojan. Such malicious programs may attempt to spread over 
other devices over either a wired interface or a wireless one. 

• Legal issues: Mobile devices might be involved in crimes, which can cross 
geographical boundaries. In order to tackle these multijurisdictional issues, the 
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forensic examiner should be aware of the nature of the crime and the regional 
laws. 


The mobile phone evidence extraction 
process 

Evidence extraction and forensic examination of each mobile device may differ. However, 
following a consistent examination process will assist the forensic examiner to ensure that 
the evidence extracted from each phone is well documented and that the results are 
repeatable and defendable. There is no well-established standard process for mobile 
forensics. However, the following figure provides an overview of process considerations for 
extraction of evidence from mobile devices. All methods used when extracting data from 
mobile devices should be tested, validated, and well documented. 



Mobile phone evidence extraction process 

O A great resource for handling and processing mobile devices can be found 

at http : / /digital-forensics . sans . org/media/mobile-device-fo 
rensic-process-v3 .pdf. 
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As shown in the preceding figure, forensics on a mobile device includes several phases 
starting from evidence intake phase to Archiving phase. The following sections provide an 
overview of various considerations across all the phases. 


The evidence intake phase 

The evidence intake phase is the starting phase and entails request forms and paperwork to 
document ownership information and the type of incident the mobile device was involved 
in, and it outlines the type of data or information the requester is seeking. Developing 
specific objectives for each examination is the critical part of this phase. It serves to clarify 
the examiner's goals. Also, while seizing the device, care should be taken not to modify any 
data present on the device. At the same time, any opportunity that might help the 
investigation should not be missed. For example, at the time of seizing the device, if the 
device is unlocked, then try to disable the passcode. 

The identification phase 

The forensic examiner should identify the following details for every examination of a 
mobile device: 

• The legal authority 

• The goals of the examination 

• The make, model, and identifying information for the device 

• Removable and external data storage 

• Other sources of potential evidence 

We will discuss each of them in the following sections. 


The legal authority 

It is important for the forensic examiner to determine and document what legal authority 
exists for the acquisition and examination of the device as well as any limitations placed on 
the media prior to the examination of the device. For example, if the mobile device is being 
searched pursuant to a warrant, the examiner should be mindful of confining the search to 
the limitations of the warrant. 
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The goals of the examination 

The examiner will identify how in-depth the examination needs to be based upon the data 
requested. The goal of the examination makes a significant difference in selecting the tools 
and techniques to examine the phone and increases the efficiency of the examination 
process. 


The make, model, and identifying information for the 
device 

As part of the examination, identifying the make and model of the phone assists in 
determining what tools would work with the phone. For all phones, the manufacturer, 
model number, carrier and the current phone number associated with the cellular phone 
should be identified and documented. 

Removable and external data storage 

Many mobile phones provide an option to extend the memory with removable storage 
devices, such as the Trans Flash Micro SD memory expansion card. In cases when such a 
card is found in a mobile phone that is submitted for examination, the card should be 
removed and processed using traditional digital forensic techniques. It is wise to also 
acquire the card while in the mobile device to ensure that data stored on both the handset 
memory and card are linked for easier analysis. This will be discussed in detail in upcoming 
chapters. 


Other sources of potential evidence 

Mobile phones act as good sources of fingerprint and other biological evidence. Such 
evidence should be collected prior to the examination of the mobile phone to avoid 
contamination issues unless the collection method will damage the device. Examiners 
should wear gloves when handling the evidence. 


The preparation phase 

Once the mobile phone model is identified, the preparation phase involves research 
regarding the particular mobile phone to be examined and the appropriate methods and 
tools to be used for acquisition and examination. This is generally done based on the device 
model, underlying operating system, its version, and so on. Also, choosing tools for 
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examination of a mobile device will be determined by factors such as the goal of the 
examination, resources available, the type of cellular phone to be examined and the 
presence of any external storage capabilities. 


The isolation phase 

Mobile phones are, by design intended to communicate via cellular phone networks, 
Bluetooth, Infrared, and wireless (Wi-Fi) network capabilities. When the phone is connected 
to a network, new data is added to the phone through incoming calls, messages, and 
application data, which modifies the evidence on the phone. Complete destruction of data is 
also possible through remote access or remote wiping commands. For this reason, isolation 
of the device from communication sources is important prior to the acquisition and 
examination of the device. Network isolation can be done by placing the phone in radio 
frequency shielding cloth and then putting the phone in airplane or flight mode. The 
airplane mode disables a device's communication channels such as cellular radio, Wi-Fi, 
and Bluetooth. However, if the device is screen locked, then this is not possible. Also, since 
Wi-Fi is now available in airplanes, some devices have Wi-Fi access now enabled in airplane 
mode. An alternate solution is isolation of the phone through the use of faraday bags, which 
block the radio signals to or from the phone. Faraday bags contain materials that block 
external static electrical fields (including radio waves). Thus, Faraday bags shield seized 
mobile devices from external interference to prevent wiping and tracking. To work more 
conveniently with the seized devices, Faraday tents and rooms also exist. 


The processing phase 

Once the phone has been isolated from communication networks, the actual processing of 
the mobile phone begins. The phone should be acquired using a tested method that is 
repeatable and is as forensically sound as possible. Physical acquisition is the preferred 
method as it extracts the raw memory data and the device is commonly powered off during 
the acquisition process. On most devices, the smallest amount of changes occur to the 
device during physical acquisition. If physical acquisition is not possible or fails, an attempt 
should be made to acquire the file system of the mobile device. A logical acquisition should 
always be obtained as it may contain only the parsed data and provide pointers to examine 
the raw memory image. These acquisition methods are discussed in detail in the later 
chapters. 
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The verification phase 

After processing the phone, the examiner needs to verify the accuracy of the data extracted 
from the phone to ensure that data has not been modified. The verification of the extracted 
data can be accomplished in several ways. 

Comparing extracted data to the handset data 

Check if the data extracted from the device matches the data displayed by the device. The 
data extracted can be compared to the device itself or a logical report, whichever is 
preferred. Remember, handling the original device may make changes to the only 
evidence— the device itself. 


Using multiple tools and comparing the results 

To ensure accuracy, use multiple tools to extract the data and compare results. 

Using hash values 

All image files should be hashed after acquisition to ensure that data remains unchanged. If 
file system extraction is supported, the examiner extracts the file system and then computes 
hashes for the extracted files. Later, any individually extracted file hash is calculated and 
checked against the original value to verify the integrity of it. Any discrepancy in a hash 
value must be explainable (for example, the device was powered on and then acquired 
again, thus the hash values are different). 


The document and reporting phase 

The forensic examiner is required to document throughout the examination process in the 
form of contemporaneous notes relating to what was done during the acquisition and 
examination. Once the examiner completes the investigation, the results must go through 
some form of peer review to ensure that the data is checked and the investigation is 
complete. The examiner's notes and documentation may include information such as the 
following: 

• The examination start date and time 

• The physical condition of the phone 

• Photos of the phone and individual components 
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• Phone status when received-turned on or off 

• Phone make and model 

• Tools used for the acquisition 

• Tools used for the examination 

• Data found during the examination 

• Notes from peer review 


The presentation phase 

Throughout the investigation, it is important to make sure that the information extracted 
and documented from a mobile device can be clearly presented to any other examiner or to 
a court. Creating a forensic report of data extracted from the mobile device during 
acquisition and analysis is important. This may include data in both paper and electronic 
formats. Your findings must be documented and presented in a manner that the evidence 
speaks for itself when in court. The findings should be clear, concise, and repeatable. 
Timeline and link analysis, features offered by many commercial mobile forensics tools, will 
aid in reporting and explaining findings across multiple mobile devices. These tools allow 
the examiner to tie together the methods behind the communication of multiple devices. 

The archiving phase 

Preserving the data extracted from the mobile phone is an important part of the overall 
process. It is also important that the data is retained in a usable format for the ongoing court 
process, for future reference, should the current evidence file become corrupt, and for 
record keeping requirements. Court cases may continue for many years before the final 
judgment is arrived at, and most jurisdictions require that data be retained for long periods 
of time for the purposes of appeals. As the field and methods advance, new methods for 
pulling data out of a raw, physical image may surface, and then the examiner can revisit the 
data by pulling a copy from the archives. 


Practical mobile forensic approaches 

Similar to any forensic investigation, there are several approaches that can be used for the 
acquisition and examination/analysis of data from mobile phones. The type of mobile 
device, the operating system, and the security setting generally dictate the procedure to be 
followed in a forensic process. Every investigation is distinct with its own circumstances, so 
it is not possible to design a single definitive procedural approach for all cases. The 
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following details outline the general approaches followed in extracting data from mobile 
devices. 


Mobile operating systems overview 

One of the major factors in the data acquisition and examination/analysis of a mobile phone 
is the operating system. Starting from low-end mobile phones to smartphones, mobile 
operating systems have come a long way with a lot of features. Mobile operating systems 
directly affect how the examiner can access the mobile device. For example. Android OS 
gives terminal-level access whereas iOS does not give such an option. A comprehensive 
understanding of the mobile platform helps the forensic examiner make sound forensic 
decisions and conduct a conclusive investigation. While there is a large range of smart 
mobile devices, three main operating systems dominate the market, namely, Google 
Android, Apple iOS and Windows Phone. More information can be found at https : //www 
. idc . com/ prodserv/smartphone-os-market-share . j sp. This book covers forensic 
analysis of these three mobile platforms. We will cover a brief overview of leading mobile 
operating systems. 


Android 

Android is a Linux-based operating system, and it's a Google open source platform for 
mobile phones. Android is the world's most widely used smartphone operating system. 
Sources show that Apple's iOS stands second (https : / /www. netmarket share . com/oper 
ating-system-market-share . aspx?qprid=8&qpcustomd=l). Android has been 
developed by Google as an open and free option for hardware manufacturers and phone 
carriers. This makes Android the software of choice for companies who require a low-cost, 
customizable, lightweight operating system for their smart devices without developing a 
new OS from scratch. Android's open nature has further encouraged the developers to 
build a large number of applications and upload them onto Google Play later, end users can 
download the application from Android Market, which makes Android a powerful 
operating system. It is estimated that Google Play Store has more than 2 million apps at the 
time of writing this book. More details on Android are covered in 
Chapter 7, Understanding Android. 


iOS 

iOS, formerly known as the iPhone operating system, is a mobile operating system 
developed and distributed solely by Apple Inc. iOS is evolving into a universal operating 
system for all Apple mobile devices, such as iPad, iPod touch, and iPhone. iOS is derived 
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from OS X, with which it shares the Darwin foundation, and is therefore a Unix-like 
operating system. iOS manages the device hardware and provides the technologies 
required to implement native applications. iOS also ships with various system applications, 
such as Mail and Safari, which provide standard system services to the user. iOS native 
applications are distributed through AppStore, which is closely monitored by Apple. More 
details about iOS are covered in Chapter 2, Understanding the Internals ofiOS Devices. 


Windows phone 

Windows phone is a proprietary mobile operating system developed by Microsoft for 
smartphones and pocket PCs. It is the successor to Windows mobile and primarily aimed at 
the consumer market rather than the enterprise market. The Windows Phone OS is similar 
to the Windows desktop OS, but it is optimized for devices with a small amount of storage. 
Windows Phone basics and forensic techniques are discussed in Chapter 12 , Windows 
Phone Forensics. 


Mobile forensic tool leveling system 

Mobile phone forensic acquisition and analysis involves manual effort and the use of 
automated tools. There are a variety of tools that are available for performing mobile 
forensics. All the tools have their pros and cons, and it is fundamental that you understand 
that no single tool is sufficient for all purposes. So understanding various types of mobile 
forensic tools is important for forensic examiners. When identifying the appropriate tools 
for the forensic acquisition and analysis of mobile phones, a mobile device forensic tool 
classification system (shown in the following figure) developed by Sam Brothers comes in 
handy for the examiners: 
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Cellular phone tool levelling pyramid (Sam Brothers, 2009) 

The objective of the mobile device forensic tool classification system is to enable an 
examiner to categorize the forensic tools based upon the examination methodology of the 
tool. Starting at the bottom of the classification and working upward, the methods and the 
tools generally become more technical, complex, and forensically sound, and require longer 
analysis times. There are pros and cons of performing an analysis at each layer. The forensic 
examiner should be aware of these issues and should only proceed with the level of 
extraction that is required. Evidence can be destroyed completely if the given method or 
tool is not properly utilized. This risk increases as you move up in the pyramid. Thus, 
proper training is required to obtain the highest success rate in data extraction from mobile 
devices. 

Each existing mobile forensic tool can be classified under one or more of the five levels. The 
following sections contain a detailed description of each level. 


Manual extraction 

The manual extraction method involves simply scrolling through the data on the device and 
viewing the data on the phone directly through the use of the device's keypad or 
touchscreen. The information discovered is then photographically documented. The 
extraction process is fast and easy to use, and it will work on almost every phone. This 
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method is prone to human error, such as missing certain data due to unfamiliarity with the 
interface. At this level, it is not possible to recover deleted information and grab all the data. 
There are some tools, such as Project- A-Phone, that have been developed to aid an examiner 
to easily document a manual extraction. However, this might also result in modification of 
data. For example, viewing an unread SMS can mark it as read. 

Logical extraction 

Logical extraction involves connecting the mobile device to forensic hardware or to a 
forensic workstation via a USB cable, a RJ-45 cable. Infrared, or Bluetooth. Once connected, 
the computer initiates a command and sends it to the device, which is then interpreted by 
the device processor. Next, the requested data is received from the device's memory and 
sent back to the forensic workstation. Later, the examiner can review the data. Most of the 
forensic tools currently available work at this level of the classification system. The 
extraction process is fast, easy to use, and requires little training for the examiners. On the 
flip side, the process may write data to the mobile and might change the integrity of the 
evidence. In addition, deleted data is not generally accessible with this procedure. 


Hex dump 

A hex dump, also referred to as a physical extraction, is achieved by connecting the device 
to the forensic workstation and pushing unsigned code or a bootloader into the phone and 
instructing the phone to dump memory from the phone to the computer. Since the resulting 
raw image is in binary format, technical expertise is required to analyze it. The process is 
inexpensive, provides more data to the examiner, and allows the recovering of the deleted 
files from the device-unallocated space on most devices. 


Chip-off 

Chip-off refers to the acquisition of data directly from the device's memory chip. At this 
level, the chip is physically removed from the device and a chip reader or a second phone is 
used to extract data stored on it. This method is more technically challenging as a wide 
variety of chip types are used in mobiles. The process is expensive and requires hardware 
level knowledge as it involves the desoldering and heating of the memory chip. Training is 
required to successfully perform a chip-off extraction. Improper procedures may damage 
the memory chip and render all data unsalvageable. When possible, it is recommended that 
the other levels of extraction are attempted prior to chip-off since this method is destructive 
in nature. Also, the information that comes out of memory is in a raw format and has to be 
parsed, decoded, and interpreted. The chip-off method is preferred in situations where it is 
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important to preserve the state of memory exactly as it exists on the device. It is also the 
only option when a device is damaged but the memory chip is intact. 

The chips on the device are often read using the Joint Test Action Group (JTAG) method. 
The JTAG method involves connecting to Test Access Ports (TAPs) on a device and 
instructing the processor to transfer the raw data stored on memory chips. The JTAG 
method is generally used with devices that are operational but inaccessible using standard 
tools. Both of these techniques also work even when the device is screen locked. 


Micro read 

The process involves manually viewing and interpreting data seen on the memory chip. 

The examiner uses an electron microscope and analyzes the physical gates on the chip and 
then translates the gate status to 0's and l's to determine the resulting ASCII characters. The 
whole process is time-consuming and costly, and it requires extensive knowledge and 
training on memory and the file system. Due to the extreme technicalities involved in micro 
read, it would be only attempted for high-profile cases equivalent to a national security 
crisis after all other level extraction techniques have been exhausted. The process is rarely 
performed and is not well documented at this time. Also, there are currently no commercial 
tools available to perform a micro read. 


Data acquisition methods 

Data acquisition is the process of imaging or otherwise extracting information from a digital 
device and its peripheral equipment and media. Acquiring data from a mobile phone is not 
as simple as a standard hard drive forensic acquisition. The following points break down 
the three types of forensic acquisition methods for mobile phones: physical, logical, 
and manual. These methods may have some overlap with a couple of levels discussed in 
the mobile forensics tool leveling system. The amount and type of data that can be collected 
will vary depending on the type of acquisition method being used. 


Physical acquisition 

Physical acquisition of mobile phones is performed using mobile forensic tools and 
methods. Physical extraction acquires information from the device by direct access to the 
flash memory. Flash memory is a nonvolatile memory and is primarily used in memory 
cards and USB flash drives as solid state storage The process creates a bit-for-bit copy of an 
entire file system, similar to the approach taken in computer forensic investigations. A 
physical acquisition is able to acquire all of the data present on a device including the 
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deleted data and access to unallocated space on most devices. 

Logical acquisition 

Logical acquisition of mobile phones is performed using the device manufacturer 
application-programming interface to synchronize the phone's contents with a computer. 
Many of the forensic tools perform a logical acquisition. However, the forensic analyst must 
understand how the acquisition occurs and whether the mobile is modified in any way 
during the process. Depending on the phone and forensic tools used, all or some of the data 
is acquired. A logical acquisition is easy to perform and only recovers the files on a mobile 
phone and does not recover data contained in unallocated space. 


Manual acquisition 

With mobile phones, physical acquisition is usually the best option, and logical acquisition 
is the second-best option. Manual extraction should be the last option when performing the 
forensic acquisition of a mobile phone. Both logical and manual acquisition can be used to 
validate findings in the physical data. During manual acquisition, the examiner utilizes the 
user interface to investigate the contents of the phone's memory. The device is used 
normally through keypad or touchscreen and menu navigation, and the examiner takes 
pictures of each screen's contents. Manual extraction introduces a greater degree of risk in 
the form of human error, and there is a chance of deleting the evidence. Manual acquisition 
is easy to perform and only acquires the data that appears on a mobile phone. 


Potential evidence stored on mobile phones 

The range of information that can be obtained from mobile phones is detailed in this 
section. Data on a mobile phone can be found in a number of locations: SIM card, external 
storage card, and phone memory. In addition, the service provider also stores 
communication-related information. The book primarily focuses on data acquired from the 
phone memory. Mobile device data extraction tools recover data from the phone's memory. 
Even though data recovered during a forensic acquisition depends on the mobile model, in 
general, the following data is common across all models and useful as evidence. Note that 
most of the following artifacts contain date and timestamps: 

• Address Book: This stores contact names, numbers, e-mail addresses, and so on 

• Call History: This contains dialed, received, missed calls, and call durations 

• SMS: This contains sent and received text messages 
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• MMS: This contains media files such as sent and received photos and videos 

• E-mail: This contains sent, drafted, and received e-mail messages 

• Web browser history: This contains the history of websites that were visited 

• Photos: This contains pictures that are captured using the mobile phone camera, 
those downloaded from the Internet, and the ones transferred from other devices 

• Videos: This contains videos that are captured using the mobile camera, those 
downloaded from the Internet, and the ones transferred from other devices 

• Music: This contains music files downloaded from the Internet and those 
transferred from other devices 

• Documents: This contains documents created using the device's applications, 
those downloaded from the Internet, and the ones transferred from other devices 

• Calendar: This contains calendar entries and appointments 

• Network communication: This contains GPS locations 

• Maps: This contains looked-up directions, and searched and downloaded maps 

• Social networking data: This contains data stored by applications, such as 
Facebook, Twitter, Linkedln, Google+, and WhatsApp 

• Deleted data: This contains information deleted from the phone 


Rules of evidence 

Courtrooms rely more and more on the information inside a mobile phone as vital 
evidence. Prevailing evidence in court requires a good understanding of the rules of 
evidence. Mobile forensics is a relatively new discipline and laws dictating the validity of 
evidence are not widely known. However, there are five general rules of evidence that 
apply to digital forensics and need to be followed in order for evidence to be useful. 
Ignoring these rules makes evidence inadmissible, and your case could be thrown out. 

These five rules are: admissible, authentic, complete, reliable, and believable: 

• Admissible: This is the most basic rule and a measure of evidence validity and 
importance. The evidence must be preserved and gathered in such a way that it 
can be used in court or elsewhere. Many errors can be made that could cause a 
judge to rule a piece of evidence as inadmissible. For example, evidence that is 
gathered using illegal methods is commonly ruled inadmissible. 

• Authentic: The evidence must be tied to the incident in a relevant way to prove 
something. The forensic examiner must be accountable for the origin of the 
evidence. 

• Complete: When evidence is presented, it must be clear and complete and should 
reflect the whole story. It is not enough to collect evidence that just shows one 
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perspective of the incident. Presenting incomplete evidence is more dangerous 
than not providing any evidence at all as it could lead to a different judgment. 

• Reliable: Evidence collected from the device must be reliable. This depends on 
the tools and methodology used. The techniques used and evidence collected 
must not cast doubt on the authenticity of the evidence. If the examiner used 
some techniques that cannot be reproduced, the evidence is not considered unless 
they were directed to do so. This would include possible destructive methods 
such as chip-off extraction. 

• Believable: A forensic examiner must be able to explain, with clarity and 
conciseness, what processes they used and the way the integrity of the evidence 
was preserved. The evidence presented by the examiner must be clear, easy to 
understand, and believable by jury. 


Good forensic practices 

Good forensic practices apply to the collection and preservation of evidence. Following 
good forensic practices ensures that evidence will be accepted in a court as being authentic 
and accurate. Modification of evidence, either intentionally or accidentally, can affect the 
case. So, understanding the best practices is critical for forensic examiners. 


Securing the evidence 

With advanced smartphone features such as Find My iPhone and remote wipes, securing a 
mobile phone in a way that it cannot be remotely wiped is of great importance. Also, when 
the phone is powered on and has service, it constantly receives new data. To secure the 
evidence, use the right equipment and techniques to isolate the phone from all networks. 
With isolation, the phone is prevented from receiving any new data that would cause active 
data to be deleted. 


Preserving the evidence 

As evidence is collected, it must be preserved in a state that is acceptable in court. Working 
directly on the original copies of evidence might alter it. So, as soon as you recover a raw 
disk image or files, create a read-only master copy and duplicate it. In order for evidence to 
be admissible, there must be a method to verify that the evidence presented is exactly the 
same as the original collected. This can be accomplished by creating a hash value of the 
image. After duplicating the raw disk image or files, compute and verify the hash values for 
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the original and the copy to ensure that the integrity of the evidence is maintained. Any 
changes in hash values should be documented and explainable. All further processing or 
examination should be performed on copies of the evidence. Any use of the device might 
alter the information stored on the handset. So, only perform the tasks that are absolutely 
necessary. 

Documenting the evidence 

Ensure that you document all the methods and tools that are used to collect and extract the 
evidence. Detail your notes so that another examiner can reproduce them. Your work must 
be reproducible; if not, a judge may rule it inadmissible. 


Documenting all changes 

It's important to document the entire recovery process, including all the changes made 
during the acquisition and examination. For example, if the forensic tool used for the data 
extraction sliced up the disk image to store it, this must be documented. All changes to the 
mobile device, including power cycling and syncing, should be documented in your case 
notes. 


Summary 

Mobile devices store a wide range of information such as SMS, call logs, browser history, 
chat messages, location details, and so on. Mobile device forensics includes many 
approaches and concepts that fall outside of the boundaries of traditional digital forensics. 
Extreme care should be taken while handling the device right from evidence intake phase to 
archiving phase. Examiners responsible for mobile devices must understand the different 
acquisition methods and the complexities of handling the data during analysis. Extracting 
data from a mobile device is half the battle. The operating system, security features, and 
type of smartphone will determine the amount of access you have to the data. It is 
important to follow sound forensic practices and make sure that the evidence is unaltered 
during the investigation. 

The next chapter will provide insight to iOS forensics. You will learn about the file system 
layout, security features, and the way files are stored on the iOS device. 
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2 

Understanding the Internals of 

iOS Devices 


As of November 2015, Apple had sold more than 1 billion iOS devices according to released 
sales records, and these numbers are expected to grow. While iOS is the leading operating 
system for tablets worldwide. Android continues to be the leading operating system for 
smartphones worldwide. Regardless of the statistics, if you are a forensic examiner, the 
chances are you will need to conduct an examination of an iOS device. 

In order to perform a forensic examination of an iOS device, the examiner must understand 
the internal components and inner workings of that device. Developing an understanding 
of the underlying components of a mobile device will help the forensic examiner 
understand the criticalities involved in the forensic process, including what data can be 
acquired, where the data is stored, and what methods can be used to access the data from 
that device. So, before we delve into the examination of iOS devices, it is necessary to know 
the different models that exist and their internal components. Throughout this book, we 
will perform forensic acquisition and analysis on iOS devices to include the iPhone, iPad, 
and Apple Watch. 

The goal of this chapter is to introduce you to the iOS device technology. We will cover 
details that may often get overlooked, but will help you during your forensic investigation. 
You must understand the different iOS devices and how the data is stored on the devices 
before you can successfully extract it. 


Understanding the Internals of iOS Devices 


In this chapter, we will cover the following topics in detail: 

• iPhone models and hardware 

• iPad models and hardware 

• Apple Watch models and hardware 

• iOS overview 

• HFS Plus overview 

• Jailbreaking 


iPhone models 

The iPhone is among the most popular mobile phones on the market. Apple released the 
first generation iPhone in June 2007. Ever since the first release, the iPhone has gained a lot 
of popularity due to its advanced functionality and usability. The introduction of the iPhone 
has redefined the entire world of mobile computing. Consumers started looking for faster 
and more efficient phones. Various iPhone models exist now with different features and 
storage capabilities to serve the consumer requirements. The following table lists all iPhone 
models with their initial iOS versions: 


Device 

Model 

Initial OS 

Identifier 

Release 

date 

iPhone 2G 

A1203 

iPhone OS 1 .0 

iPhone 1,1 

June 2007 

iPhone 3G 

A1241 


iPhone 1,2 

July 2008 

A1324 


iPhone 3GS 

A1303 

iPhone OS 3.0 

iPhone 2,1 

June 2009 

A1325 

iPhone 4 - GSM 

A1332 

iOS 4.0 

iPhone 3,1 


iPhone 4 - CDMA 

A1349 

iPhone 3,2 


iPhone 4S 

A1387 

iOS 5.0 

iPhone 4,1 

October 

A1431 

2011 

iPhone 5 

A1428 


iPhone 5,1 

September 

2012 

iPhone 5 rev2 

A1429 

iOS 6.0 

iPhone 5,2 

A 1442 



iPhone 5C- GSM 

A1456 


iPhone 5,3 


A1532 




A1507 

iOS 7.0 



iPhone SC - CDMA 

A15I6 

iPhone 5,4 


A1526 




A1529 



September 

iPhone 5S- GSM 

A1433 

iOS 7.0 

iPhone 6,1 

2013 

A1533 



A1457 




iPhone 5S- CDMA 

A1518 

iOS 7.0 

iPhone 6,2 


A1528 



A1530 
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iPhone 6 - CDMA 

A1549 





A1586 


iPhone 7,2 

September 


A1589 


2014 

iPhone 6 - GSM 

A1549 

iOS 8.0 



iPhone 6 Plus - CDMA 

A1522 




A1524 


iPhone 7,1 

September 


A1522 


2014 

iPhone 6 Plus - GSM 

A1593 





A1633 



September 

2015 


A1700 


iPhone 8,1 

iPhone 6S 

A1688 

iOS 9.0 




A1634 


September 

2015 


A1687 


iPhone 8,2 

iPhone 6S Plus 

A1699 





iPhone models 

The iPhones released since the first edition of Practical Mobile Forensics, the iPhones 6, 6 
Plus, 6S, and 6S Plus, remain difficult when dealing with physical forensic acquisition 
methods. Just like the devices released since the iPhone 5, there is no method or tool 
available to physically recover data from these devices, unless they are jailbroken. 

However, the file system and a logical acquisition can be obtained if the iPhone is unlocked. 
Acquisition methods for data extraction are available and will be discussed in Chapter 
4, Data Acquisition from iOS Devices, and Chapter 5, Data Acquisition from iOS Backups. 

Identifying the correct hardware model 

Before examining an iPhone, it is necessary to identify the correct hardware model and the 
firmware version installed on the device. Knowing the iPhone details helps you to 
understand the criticalities and possibilities of obtaining evidence from the iPhone. For 
example, in many cases, the device passcode is required in order to obtain the file system or 
logical image. Even if the device is supported physically, the passcode is needed to decrypt 
artifacts such as e-mail and passwords. Depending on the iOS version, device model, and 
passcode complexity, it may be possible to obtain the device passcode using a brute force 
attack. 

There are various ways to identify the hardware of a device. The easiest way to identify the 
hardware of a device is by observing the Model No. displayed on the back of the device. 
The following image shows the model number etched on the back of the casing. Apple's 
knowledge base articles can be helpful for this purpose. Details on identifying iPhone 
models can be found at http : // support . apple . com/kb/HT3939. 
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iPhone 

f 16GB ] 

Designed bv App le in California Assembled in China 
Model No A1303 FCC ID: BCGA1303B 1C ID S/SC AA303U 



iPhone model number located on the back of the case 


The firmware version of an iPhone can be found by accessing the Settings option and then 
navigating to General I About I Version, as shown in the following screenshot. The 
purpose of the firmware is to enable certain features and assist with the general functioning 
of the device. 


••ooo Verizon » 9:27 PM * 44% 

< General About 

Name Heather Mahalik's iPhone 


Network 

Verizon 

Songs 

96 

Videos 

79 

Photos 

716 

Applications 

68 

Capacity 

11.8 G8 

Available 

441 MB 

Version 

9.2 (13C75) 

Carrier 

Verizon 23.2 


The iPhone About screen, displaying firmware Version 9.2 (13C75) 


[ 30 ] 




Understanding the Internals ofiOS Devices 


Alternatively, the ideviceinfo command-line tool available in the libimobiledevice 
software library (http : / /www. libimobiledevice . org/) can be used to identify the 
iPhone model and its iOS version. The library allows you to communicate with an iPhone 
even if the device is locked by a passcode. The software library was developed by Nikias 
Bassen (pimskeks), and it was compiled for Mac OS X by Ben Clayton (benvium). 

To obtain the iPhone model and its iOS version information on Mac OS X 10.10.4, follow 
these steps: 

1. Open the terminal application. 

2. From the command line, run the following command to download 

the libimobiledevice library: 

$ git clone https://github.com/benvium/libimobiledevice- 
macosx . git -/Desktop/libimobiledevice-macosx/ 

The command creates the libimobiledevice-macosx directory on the user's 
desktop and places the libimobiledevice command-line tools onto it. 

3. Navigate to the libimobiledevice-macosx directory, as follows: 

$ cd -/Desktop/libimobiledevice-macosx/ 

4. Create and edit the . bash_prof ile file using the nano command, as follows: 

$ nano ~/ . bash_prof ile 

5. Add the following two lines to the .bash_profile file, as follows: 

export DYLD_LIBRARY_PATH=~ /Desktop/ libimobiledevice- 
macosx/ : $DYLD_LIBRARY_PATH 

PATH=${PATH} : -/Desktop/libimobiledevice-macosx/ 

6. Press Ctrl + X, type the letter y, and hit Enter to save the file. 

7. Return to the terminal and run the following command: 

$ source ~/ . bash_profile 

8. Connect the iPhone to the Mac workstation using a USB cable and run 
the ideviceinfo command with the -s option: 

$ . /ideviceinfo -s 

Output of the ideviceinfo command displays the iPhone identifier, internal name, and 
the iOS version, as shown here: 
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# # # libimobiledevice-macosx — bash — 85x29 

Heathers-MacBook-Pro-2: libimobiledevice-macosx HeatherWorkS source ~/.bash_profile 
Heathers-MacBook-Pro-2: libimobiledevice-macosx HeatherWorkS ./ideviceinfo -s 
BasebandCertld : 3554301762 
BasebandKeyHashln format ion: 

AKeyStatus: 2 

SKeyHash: 7MQEU' ■ ■ ■ 

SKeyStatus: 0 

BasebandSerialNumber: XtA;; | 

BasebandVersion: 6.01.00 

Boardld: 0 

BuildVersion: 13C75 

ChipID: 35168 

DeviceClass: iPhone 

DeviceColor: #ele4e3 

DeviceName: Heather Mahalik s iPhone 

DielD: 8481629079760 

HardwareModel: N51AP 

Partit ionType: 

ProductName: iPhone OS 
ProductType: iPhone6,l 
ProductVersion: 9.2 
ProductionSOC: true 
ProtocolVersion: 2 
TelephonyCapability: true 
UniqueChipIO: 848 Ml 1 

UniqueDevicelD: 611«>: 1 .■ . m .MT : W * ;i3fc2 

UntrustedHostBUID: CC00B612-579E-48DC-B779-AFD5D7539C82 
WiFiAddress: dc : 1 ■ ■ ■: 4d 

Heathers-MacBook-Pro-2: libimobiledevice-macosx HeatherWorkS | 


Output from libimobiledevice displaying firmware Version 9.2 (13C75) 


Free tools, such as iExplorer and others, will provide access to similar iOS device 
information on a Windows PC, as shown in the following screenshot. Both Mac and 
Windows methods for recovering iPhone device information will work on the iPad devices 
as well. Here, iExplorer is being used to obtain device information from the iPhone: 


▼ □ Heather Mahalik’s iPhone 

^ Media Library 
▼ O Backup 

► *0 Backup Explorer 
<S> Contacts 
Messages 



Heather Mahalik’s iPhone 

Capacity: 11.8 GB 
►Software Version: 9.2 
Firmware Version: iBoot-2817. 20.26 
Serial Number DNP W ■ 
Phone Number ( 


iExplorer displaying iPhone identifiers 


Every release of the iPhone comes with improved or newly added features. As previously 
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stated in this chapter, knowing the iPhone details helps you understand the criticalities and 
possibilities of obtaining evidence from the iPhone. The examiner must know the model of 
the device to ensure that their tools and methodologies support that iPhone. They must 
determine the internal storage size of the iPhone to ensure that the evidence container is 
large enough for the entire forensic image. Most tools will not alert the examiner that there 
is not enough disk space on the evidence drive until space has run out. This will waste time 
and force the examiner to acquire the device a second time. Finally, the network capabilities 
of the device must be noted, so the examiner properly isolates the device to prevent remote 
access or wiping during examination. This will be discussed further in Chapter 4, Data 
Acquisition from iOS Devices. 

The following table shows the specifications and features of legacy and current iPhone 
models: 


Specification 

iPhone 

iPhone 3G 

iPhone 3GS 

System on chip 

Samsung Chip 

Samsung Chip 

Samsung Chip 

Onboard RAM 

128 MB 

128 MB 

256 MB 

Connectivity 

Wi-Fi, B hi etooth 

2.0, GSM 

Wi-Fi, Bluetooth 

2.0, 

GSM/UMTS/HS 

DP A, GPS 

Wi-Fi, Bluetooth 

2.1, GSM, 

UMT S/HSDP A, 

GPS 

Camera 

(megapixel) 

2 

2 

3 

Front camera 

N/A 

N/A 

N/A 

Storage (G6) 

4, 8, 16 

8, 16 

8, 16, 32 

Colors 

Black 

Black, white 

(white not in 8 
GB) 

Black, white 

(white not in 8 
GB) 

Connector 

USB 2.0 dock 

connector 

USB 2.0 dock 

connector 

USB 2.0 dock 

connector 

SIM card form- 

factor 

Mini SIM 

Mini SIM 

Mini SIM 

Siri support 

No 

No 

No 


Specifications of legacy iPhone models 
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The later iPhone releases and features are shown in the following table: 


Specification 

iPhone 4 

iPhone 4S 

iPhone 5 

iPhone 5C 

iPhone 5S 

System on 
chip 

Apple A4 

Apple A5 

Apple A6 

Apple A6 

Apple A7 

Onboard 

RAM 

512 MB 

512 MB 

1 GB 

1GB 

1GB 

Connectivity 

Wi-Fi, 

Bluetooth 

2.1, GSM, 

UMTS/HS 

DP A/HSU 

PA, GPS 

Wi-Fi, Bluetooth 

4, GSM, 

UMTS/HSDPA/H 

SUP A, GPS 

Wi-Fi, 

Bluetooth 

4, 

UMTS/HS 

DPA+/DC 

HSDPA, 

GSM, GPS 

Wi-Fi, 

Bluetooth 4, 
UMTS/HSDP 
A+/DC- 
HSDPA/LTE, 

GSM, GPS 

Wi-Fi, 

Bluetooth 4, 
UMTS/HSDP 
A+/DC- 
HSDPA/LTty 

TD-LTE, 

GSM, GPS 

Camera 

(megapixel) 

5 

8 

8 

8 

8 

Storage (GB) 

' 8, 16, 32 

8, 16, 32, 64 

16, 32, 64 

8, 16, 32, 64 

8, 16, 32, 64 

Colors 

Black 

Black, white 

Black, 

white 

White, pink, 
yellow, blue, 

or green 

Silver, space 
gray, or gold 

Connector 

USB 2.0 

dock 

connector 

USB 2.0 dock 

connector 

Lightning 

connector 

Lightning 

connector 

Lightning 

connector 

SIM card form 

factor 

Micro 

SIM 

Micro SIM 

Nano-SIM 

Nano -SIM 

Nano-SIM 

Siri support 

No 

Yes 

Yes 

Yes 

Yes 


Specifications of the current iPhone models 

One of the major changes in the iPhone 5, iPhone 5C, and iPhone 5S is the lightening 
connector, which is used to charge and synchronize the device with the computer. Devices 
prior to the iPhone 5 use a 30-pin USB dock connector, whereas the newer iPhones use an 
eight-pin lightning connector. 

The most recent iPhone releases and features are shown in the following table: 
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Specification 

iPhone 6 

iPhone 6 Plus 

iPhone 6S 

iPhone 6S Plus 

System on 
chip 

Apple A8 

Apple A8 

Apple A9 

Apple A9 

CPU 

1.4 GHz 

1.4 GHz 

1.8 GHz 

IB GHz 

Onboard RAM 

1GB 

1GB 

2 GB 


Screen size (in 
inches) 

4.7 

5.5 

4.7 

5.5 

Connectivity 

Wi-Fi, 

Bluetooth 4.2, 

UMTS/HSDP 

A+/DC- 

HSDPA/LTE, 

CDMA, 

GSM, GPS 

Wi-Fi, Bluetooth 

42, 

UMTS/HSDP A+/ 

DC-HSDPA/LTE, 

CDMA, GSM, 

GPS 

Wi-Fi, 

Bluetooth 4.2, 

UMTS/HSDP A 
+/DC- 

hsdpa/lte, 

CDMA, GSM, 

GPS 

Wi-Fi, Bluetooth 4.2, 

UMTS/HSDPA+/DC- 
HSDPA/LTE, CDMA, 

GSM, GPS 

Camera 

(megapixel) 

8 

8 

12 

12 

Storage (GB) 

16, 64, 128 

16, 64, 128 

16, 64, 128 

16, 64, 128 

Colors 

Silver, Gold, 
Space Gray 

Silver, Gold, 
Space Gray 

Silver, Rose 

Gold, Gold, 
Space Gray 

Silver, Rose Gold, 
Gold, Space Gray 

Connector 

Lightning 

connector 

Lightning 

connector 

Lightning 

connector 

Lightning connector 

SIM card form- 

factor 

Nano-SIM 

Nano-SIM 

Nano-SIM 

Nano-SIM 

Siri support 

Yes 

Yes 

Yes 

Yes 


Specifications of the most recent iPhone models 

Again, some familiarity with iPhone device hardware will aid the examiner in determining 
how to handle the device during a forensic investigation. Certain models enforce full disk 
encryption, while older models do not. Encrypted devices require additional steps during 
acquisition if access is even possible. The examiner must be prepared for all hurdles they 
may be required to clear during the acquisition and analytical stages of the investigation. In 
addition, knowing the capabilities that iPhone has and the initial and current OS version 
makes a difference is the data you will be able to recover from the device. Apple is not 
consistent with data storage locations across iOS versions. Thus, the examiner must know 
the original version installed when the phone was first in use to ensure that the forensic 
tools do not overlook data that could aid in the investigation. Topics such as iOS upgrades 
will be discussed in Chapter 6, iOS Data Analysis and Recovery. 
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iPhone hardware 

The iPhone is a collection of modules, chips, and electronic components from different 
manufacturers. Due to the complexities of the iPhone, the list of hardware components is 
extensive and each device should be researched for internal components. 

The following images show the internals of iPhone 6. The images were taken after 
dismantling the iPhone 6. Internal images for all iPhones can be found in the teardown 
section at http : / / www . if ixit . com/Device/ iPhone. 



The iPhone 6 teardown image-side i (https : / / www . ifixit . com/Teardown/ iPhonet 6+Teardown/ 2 92 1 

3) 
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The following is the image shows the back of the iPhone 6: 



The iPhone 6 teardown image-side 2 (https : / / www . ifixit . com/Teardown/ iPhone+ 6+Teardown/ 2 92 1 

3) 


iPad models 

The Apple iPhone changed the way cell phones are produced and used. Similarly, the iPad, 
a version of the tablet computer introduced in January 2010, squashed the sales of 
notebooks. With the iPad, individuals can shoot videos, take photos, play music, read 
books, browse the Internet, and do much more. Various iPad models exist now with 
different features and storage capabilities. The following table lists all the iPad models and 
their initial iOS versions. Details on identifying iPad models can be found at http : //suppo 
rt . apple . com/kb/ht5452. 
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Device 

Model 

Initial OS 

I dentif ier 

Release date 

iPad- WiFi 

A1219 

iOS32 

iPad 1,1 

Jan-10 

iPad -3G 

A1337 

iPad 1,1 

iPad 2 -WiFi 

A1395 


iPad 2,1 


iPad 2 -GSM 

A1396 


iPad 2,2 

Mar-11 

iPad 2 -CDMA 

A1397 

iOS 43 

iPad 2,3 


iPad 2 - WiFi rev 

A1395 


iPad 2,4 


iPad 3 -WiFi 

A1416 


iPad 3,1 

Mar-12 

iPad 3 - WiFi + Cellular Verizon 

A1403 

iOS 5.1 

iPad 3,2 

iPad 3 - WiFi+ Cellular AT&T 

A1430 


iPad 3,3 


iPad 4 -WiFi 

A1458 

iOS 6.0 

iPad 3,4 


iPad 4 -WiFi + Cellular AT &T 

A1459 


iPad 34 


iPad4-WiFi+ Cellular Verizon 

A1460 

iOS 6.0.1 

iPad 3,6 


iPad mini - WiFi 

A1432 

iOS 6.0 

iPad 24 

Oct-12 

iPad mini -W iFi + Ce Dular AT &T 

A1454 

iPad 2,6 


iPad mini -WiFi + Cellular Verizon 

and Spr int 

A1455 

iOS 6.0.1 

iPad 2,7 


iPad Air -WiFi 

A1474 

iOS 7.0 

iPad 4,1 


iPad Air - WiFi + Cellular 

A1475 

iOS 7.04 

iPad 4,2 


iPad mini 2 - W T iFi 

A1489 

iOS 7.0 

iPad 4,4 

Oct-13 

iPad mini 2 - WiFi + Cellular 

A1490 

iOS 7.03 

iPad 44 

iPad mini2 - WiFi + Cellular China 

A1491 

iOS 7.0 J 

iPad 4,6 

Apr-14 

iPad Air 2 -WiFi 

A1566 

iOS 8.1 

iPad 54 


iPad Air 2 -WiFi+ Cellular 

A1567 

iPad 5,4 


iPad mini 3 - WiFi 

A1599 

iOS 8.0 

iPad 4,7 

Oct-14 

iPad mini3 - WiFi + Cellular 

A1600 

iOS 8.1 

iPad 44 


iPad mini 3 - WiFi + Cellular China 

A1601 

iOS 8.1 

iPad 4,9 


iPad min 4 - WiFi 

A1538 

iOS 9.0 

iPad 5,1 


iPad mini 4 - WiFi + Cellular 

A1550 

iPad 54 

Sep-15 

iPad Pro - WiFi 

A1584 

iOS 9.1 

iPad 6,7 

iPad Pro- WiFi + Cellular 

A1652 

iPad 6,8 




iPad identifiers and release dates 
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Similar to iPhone, not all versions of the iPad are supported for physical acquisition. In 
addition, Apple has changed data storage locations in iOS versions, which affects the iPad 
devices as well. The examiner must be aware of the different models, the released and 
currently installed iOS version, storage capability, network access vectors, and more. 

Every release of the iPad comes with improved or newly added features. The following 
table shows the specifications and features of legacy iPad Wi-Fi models: 


Specification 

iPad 

iPad 2 

iPad 3 

iPad 4 

iPad Mini 

iPad Air 

System on 
chip 

Apple A4 

Apple A5 

Apple A5X 

Apple A6X 

Apple A5 

Apple A7 

Onboard 

RAM 

256 MB 

512 MB 

1 GB 

1 GB 

512 MB 

1 GB 

Screen size 

(in inches) 

9.7 

9.7 

9.7 

9.7 

7.9 

9.7 

Connectivity 

Wi-Fi, 

Bluetooth 

2.1 

Wi-Fi, 

Bluetooth 

2.1 

Wi-Fi, 

Bluetooth 4 

Wi-Fi, 

Bluetooth 

4 

Wi-R, 

Bluetooth 4 

Wi-Fi, 

Bluetooth 

4 

Camera 

(megapixel) 

N/A 

0.7 

5 

5 

5 

5 

Storage (GB) 

16,32,64 

16, 32,64 

16, 32, 64 

16,32,64, 

128 

16, 32, 64 

16, 32, 64, 

128 

Connector 

USB 2.0 

dock 

connector 

USB 2.0 

dock 

connector 

USB 2.0 

dock 

connector 

Lightning 

connector 

lightning 

connector 

Lightning 

connector 


Specifications of the legacy iPad models 
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Current iPad models are listed in the following table: 


Specification 

iPad Air 2 

iPad Mini 2 

iPad Mini 3 

iPad Mini 4 

iPad Pro 

System on 
chip 

Apple A8X 

Apple A7 

Apple A7 

Apple A8 

Apple A9X 

Onboard 

RAM 

2 GB 

2 GB 

2 GB 

2GB 

4 GB 

Screen size 

(in inches) 

9.7 

7.9 

7.9 

7.9 

1222 

Connectivity 

WiFi, LTE, 

GSM, EDGE, 

GPRS, 

Bluetooth 4.2 

WiFi, LTE, 

GSM, EDGE, 

GPRS, 

Bhretooth42 

WiFi, LTE, GSM, 

EDGE, GPRS, 

Bluetooth 4.2 

WiFi, LTE, 

GSM, EDGE, 

GPRS, 

Bluetooth 4.2 

WiFi,LTE,GSM, 

EDGE, GPRS, 

Bluetooth 42 

Camera 

(megapixel) 

8 

8 

8 

8 

8 

Storage (GB) 

16,64 or 128 

16,32,64 or 

128 

16, 64 or 128 

16, 64 or 128 

32 or 128 

Connector 

Lightning 

connector 

Lightning 

connector 

Lightning 

connector 

Lightning 

connector 

Lightning 

connector 


Specifications of the current iPad models 


Understanding the iPad hardware 

One of the key factors of the success of Apple iOS devices is the proper selection of its 
hardware components. Just like the iPhone, the iPad is also a collection of modules, chips, 
and electronic components from different manufacturers. Internal images for all iPads can 
be found in the teardown section of http : / /www . if ixit . com/Device/iPad. 

The following images show the internals of the iPad Pro. The images were taken after 
dismantling the iPad Pro cellular model and were obtained from https : //www . if ixit . c 
om/ Tear down/ iPad+Pro+Teardown/ 52599. 


[ 40 ] 


Understanding the Internals ofiOS Devices 



The iPad Proteardown image (https : / / www . if ixit . com/Teardown/ iPad+Pro+Teardown/ 52 5 99) 

The following image shows side 1 of the iPad Pro: 



The iPad Proteardown image (https : / / www . if ixit . com/Teardown/ iPad+Pro+Teardown/ 52 5 99) 
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The following image shows side 2 of the iPad Pro: 



The iPad Proteardown image (https : //www . if ixit . com/Teardown/ iPad+Pro+Teardown/ 52 5 99) 


Apple Watch models 

The Apple Watch was released in spring 2015. This smartwatch enabled users to sync 
iPhone data to the watch and leverage the watch as a way to interact with the iPhone and as 
a singular device. The Apple Watch enables users to answer calls, send and respond to SMS, 
iMessage, and e-mail, access third-party applications, use Apple maps, and more. The 
Apple Watch can only be paired with an iPhone capable of running iOS 8.2 or later, not an 
iPad. The first release of Watch OS required the watch be within Bluetooth range of the 
iPhone for full functionality, but Watch OS 2.X allows the watch to function independently 
on Wi-Fi. The Apple Watch 2 is expected to be released in late 2016. 


D e vie e 

Model 

Initial OS 

Identifier 

Release date 

Apple Watch - 38mm 

A1553 

Watch OS 1.0 

Watch 1,1 

Mar-15 

Apple Watch -42mm 

A1554 

Watch OS 1.0 

Watch 1,2 

Mar-15 
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Apple released Watch OS2 in September 2015; it offered more features, repaired bugs, and 
enabled the watch to function without an iPhone. 

The features of the current Apple Watch are listed here: 


Specification 

Apple Watch 

System on chip 

Apple SI 

Onboard RANI 

512 MB 

Size (in mm) 

38 or 42 

Connectivity 

Bluetooth 4D and 

WiFi 

Storage (GB) 

S 

Charger 

Apple Watch 
Magnetic Charger 


Understanding the Apple Watch hardware 

While there are two sizes of Apple watches, the hardware is similar for each. Apple has not 
disclosed the complete watch specifications, which forces us to rely on the little we 
currently know. 

The following image shows the internals of the Apple Watch. The images were taken after 
dismantling the Apple Watch, from https : //www. ifixit . com/Teardown/Apple+Watch 
tTeardown/ 40655. 
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Apple watch (https : / /www . ifixit . com/Teardown/Apple+Watch+Teardown/ 40655) 

The following image shows the reverse side of the Apple Watch: 



Apple watch Reverse Side (https : / / www . ifixit . com/Teardown/Apple+Watch+Teardown/ 40655) 


File system 

To better understand the forensic process of an iOS device, it is good to know about the file 
system that is used. The file system used in the iPhone and other Apple iOS devices is 
HFSX, a variation of HFS Plus with one major difference. HFSX is case sensitive whereas 
HFS Plus is case insensitive. Other differences will be discussed later in this chapter. OS X 
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uses HFS Plus by default and iOS uses HFSX. 


The HFS Plus file system 

In 1996, Apple developed a new file system, Flierarchical File System (HFS), to 
accommodate the storage of large datasets. In an HFS file system, the storage medium is 
represented as volumes. HFS volumes are divided into logical blocks of 512 bytes. The 
logical blocks are numbered from first to last on a given volume and will remain static with 
the same size as physical blocks, that is, 512 bytes. These logical blocks are grouped together 
into allocation blocks, which are used by the HFS file system to track data in a more efficient 
way. HFS uses a 16-bit value to address allocation blocks, which limits the number of 
allocation blocks to 65,535. To overcome the inefficient allocations of disk space and some of 
the limitations of HFS, Apple introduced the HFS Plus file system (http : //dubeiko . com/ 
development /FileSystems /HFSPLUS/tnl 150 . html). 

The HFS Plus file system was designed to support larger file sizes. HFS volumes are 
divided into sectors that are usually 512 bytes in size. These sectors are grouped together 
into allocation blocks. The number of allocation blocks depends on the total size of the 
volume. HFS Plus uses block addresses of 32 bits to address allocation blocks. HFS Plus 
uses journaling by default. Journaling is the process of logging every transaction to the disk, 
which helps in preventing file system corruption. The key characteristics of the HFS Plus 
file system are: efficient use of disk space, Unicode support for filenames, support for name 
forks, file compression, journaling, dynamic resizing, dynamic defragmentation, and an 
ability to boot on operating systems other than Mac OS. 


The HFS Plus volume 

The HFS Plus volume contains a number of internal structures to manage the organization 
of data. These structures include a header, an alternate header, and five special files: an 
allocation file, an extents overflow file, a catalog file, an attributes file, and a startup file. 
Among the five files, three files (the extents overflow file, the catalog file, and the attribute 
file) use a B-tree structure, a data structure that allows data to be efficiently searched, 
viewed, modified, or removed. The HFS Plus volume structure is shown in the following 
figure: 
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The volume structure is described as follows: 

• 1024 bytes: This is reserved for boot load information. 

• Volume header: This stores volume information, such as the size of allocation 
blocks, a timestamp of when the volume was created, and metadata about each of 
the five special files. 

• Allocation file: This file is used to track which allocation blocks are in use by the 
system. The file format consists of one bit for every allocation block. If the bit is 
set, the block is in use. If it is not set, the block is free. 

• Extents Overflow file: This file records the allocation blocks that are allocated 
when the file size exceeds eight blocks, which helps in locating the actual data 
when referred. Bad blocks are also recorded in the file. 

• Catalog file: This file contains information about the hierarchy of files and 
folders, which is used to locate any file and folder within the volume. 

• Attribute file: This file contains inline data attribute records, fork data attribute 
records, and extension attribute records. 

• Startup file: This file holds the information needed to assist in booting a system 
that does not have HFS Plus support. 
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• Alternate Volume header: This is a backup of the volume header, and it is 
primarily used for disk repair. 

• 512 bytes: This is reserved for use by Apple, and it is used during the 
manufacturing process. 


Disk layout 

By default, the file system is configured as two logical disk partitions: system (root or 
firmware) partition and user data partition. 

The system partition contains the OS and all of the preloaded applications used with the 
iPhone. The system partition is mounted as read-only unless an OS upgrade is in progress 
or the device is jailbroken. The partition is updated only when a firmware upgrade is 
performed on the device. During this process, the entire partition is formatted by iTunes 
without affecting any of the user data. The system partition takes only a small portion of 
storage space, normally between 0.9 GB and 2.7 GB, depending on the size of the NAND 
drive. As the system partition was designed to remain in factory state for the entire life of 
the iPhone, there is typically little useful evidentiary information that can be obtained from 
it. If the iOS device is jailbroken, files containing information regarding the jailbreak and 
user data may be resident on the system partition. Jailbreaking an iOS device allows the 
user root access to the device, but voids the manufacturer warranty. Jailbreaking will be 
discussed later in this chapter. 

The user data partition contains all user-created data ranging from music and contacts to 
third-party application data. The user data partition occupies most of the NAND memory 
and is mounted at /private/var on the device. Most of the evidentiary information can be 
found in this partition. During a physical acquisition, both the user data and system 
partitions should be captured and saved as a . dmg or . img file. Most Windows tools and 
acquisition methods will create an . img file, while Mac OSX tools and acquisition methods 
will create a . dmg file. Both of the output image files are supported by most commercial 
forensic analysis tools. 

These raw image files can be mounted as read-only for forensic analysis, which is covered 
in detail in Chapter 4, Data Acquisition from iOS Devices and Chapter 6, iOS Data Analysis 
and Recovery. 
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iPhone operating system 

iOS is Apple's most advanced and feature-rich proprietary mobile operating system. It was 
released with the first generation of the iPhone. When introduced, it was named iPhone 
OS, and it was later renamed iOS to reflect the unified nature of the operating system that 
powers all Apple iOS devices, such as the iPhone, iPod Touch, iPad, and Apple TV. iOS is 
derived from core OS X technologies and streamlined to be compact and efficient for mobile 
devices. 

It utilizes a multi-touch interface where simple gestures are used to operate and control the 
device, such as swiping your finger across the screen to move to the successive page or 
pinching your fingers to zoom. In simple terms, iOS assists with the general functioning of 
the device. iOS is really Mac OS X with the following significant differences: 

• The architecture for which the kernel and binaries are compiled is ARM-based 
rather than Intel x86_64 

• The OS X kernel is open source, whereas the iOS kernel remains closed 

• Memory management is much tighter 

• The system is hardened and does not allow access to the underlying APIs 


The iOS architecture 

iOS acts as an intermediary between the underlying hardware components and the 
applications that appear on the screen. The applications do not talk to the underlying 
hardware directly. Instead, they communicate through a well-defined system interface that 
protects the applications from hardware changes. This abstraction makes it easy to build 
applications that work on devices with different hardware capabilities. 

The iOS architecture consists of four layers: the cocoa touch layer, media layer, core services 
layer, and core OS layer, as shown in the following figure. Each layer consists of several 
frameworks that help to build an application. 
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The iOS layers 

• The Cocoa Touch layer: The Cocoa Touch layer contains the key frameworks 
required to develop the visual interface for iOS applications. Frameworks in this 
layer provide the basic application infrastructure and support key technologies, 
such as multitasking, touch-based input, and many high-level system services. 

• The Media layer: The Media layer provides the graphics and audio and video 
frameworks to create the best multimedia experience available on a mobile 
device. The technologies in this layer help developers to build applications that 
look and sound great. 

• The Core Services layer: The Core Services layer provides the fundamental 
system services that are required for the applications. All these services are not 
used by the developers though many parts of the system are built on top of them. 
The layer contains technologies to support features such as location, iCloud, and 
social media. 

• The Core OS layer: The Core OS layer is the base layer and sits directly on top of 
the device hardware. This layer deals with low-level functionalities and provides 
services such as networking (BSD sockets), memory management, threading 
(POSIX threads), file system handling, external accessories access, and inter- 
process communication. 
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iOS security 

Newer versions of iOS were designed with security at its core. At the highest level, the iOS 
security architecture appears as shown in the following figure: 


Software 


Hardware and 
Firmware 



I 


Kernel 


I 


Crypto Engine 


I 


Device Key 
Group Key 

Apple Root Certificate 


The iOS security architecture 
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Apple iOS devices such as iPhone, iPad, and iPod Touch are designed with layers of 
security. Low-level hardware features safeguard from malware attacks, and the high-level 
OS features prevent unauthorized use. A brief overview of the iOS security features is 
provided in the following sections. 


Passcodes 

Passcodes restrict unauthorized access to the device. Once a passcode is set, each time you 
turn on or wake up the device, it will ask for the passcode to access the device. iOS devices 
support simple as well as complex passcodes. iPhone 5S and later also supports touch ID 
fingerprints as a passcode, which are backed up with a simple or complex passcode. iOS 9 
released the option to use a 6-digit simple passcode instead of the legacy 4-digit option. 


Code signing 

Code signing prevents users from downloading and installing unauthorized applications 
on the device. Apple says "Code Signing is the process by which your compiled iOS application is 
sealed and identified as yours. Also, iOS devices won't run an application or load a library unless it 
is signed by a trusted party. To ensure that all apps come from a known and approved source and 
have not been tampered with, iOS requires that all executable code be signed using an Apple-issued 
certificate." 


Sandboxing 

Sandboxing mitigates the post-code-execution exploitation by placing the application into a 
tightly restricted area. Applications installed on the iOS device are sandboxed, and one 
application cannot access the data stored by the other application. Essentially, a sandbox is 
a mechanism that enforces fine-grained controls that limit an application's access to files, 
network resources, hardware, and more. 


Encryption 

On iOS devices (starting with the iPhone 4), the entire file system is encrypted with a file 
system key, which is computed from the device's unique hardware key. This key is stored 
in effaceable storage, which exists between the OS and hardware level of the device. This is 
the reason that JTAG and chip-off methods are not useful acquisition methods as the entire 
data dump will be encrypted. 
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Data protection 

Data protection is designed to protect data at rest and to make offline attacks difficult. It 
allows applications to leverage the user's device passcode in concert with the device 
hardware encryption to generate a strong encryption key. Later, the strong encryption key 
is used to encrypt the data stored on the disk. This key prevents data from being accessed 
when the device is locked, ensuring that critical information is secured even if the device is 
compromised. 

Address Space Layout Randomization 

Address Space Layout Randomization (ASLR) is an exploit mitigation technique introduced 
with iOS 4.3. ASLR randomizes the application objects' location in the memory, making it 
difficult to exploit the memory corruption vulnerabilities. 


Privilege separation 

iOS runs with the principle of least privileges. It contains two user roles: root and mobile. 
The most important processes in the system run with root user privileges. All other 
applications that the user has direct access to, such as the browser and third-party 
applications, run with mobile user privileges. 

Stack smashing protection 

Stack smashing protection is an exploit mitigation technique. It protects against buffer 
overflow attacks by placing a random and known value (called stack canary) between a 
buffer and control data on the stack. 

Data execution prevention 

Data execution prevention (DEP) is an exploit mitigation technique mechanism in which a 
processor can distinguish the portions of memory that are executable code from data. For 
example, in code injection attacks, an attacker tries to inject his vector and execute it. But, 
DEP prevents this because it recognizes the injected part as data and not code. 

Data wipe 

iOS provides the Erase All Content and Settings option to wipe the data on the iPhone. 
This type of a data wipe erases user settings and information by removing the encryption 
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keys that protects the data. As the encryption keys are erased from the device, it is not 
possible to recover the deleted data, not even during forensic investigations. Other wiping 
methods are available that overwrite the data in the device memory. More information on 
wiping can be found at http: / /support . apple . com/kb/ht2110. 


Activation Lock 

Activation Lock, introduced with iOS 7, is a theft deterrent that works by leveraging Find 
My iPhone. When Find My iPhone is enabled, it enables the Activation Lock, and your 
Apple ID and password will be required to turn off Find My iPhone, to erase your device, 
and to reactive your device. 


The App Store 

The App Store is an application distribution platform for iOS, developed and maintained by 
Apple. It is a centralized online store where users can browse and download both free and 
paid apps. These apps expand the functionality of a mobile device. As of June 2015, there 
are more than 1.5 million applications in the App Store. 

Apps available in the App Store are generally written by third-party developers. 

Developers use XCode and the iPhone SDK to develop iOS applications. Later, they submit 
the app to Apple for approval. Apple follows an extensive review process to check the app 
against the company's guidelines. If Apple approves the app, it is published to the App 
Store where users can download or buy it. The strict review process makes the App Store 
less prone to malware, but not 100% secure. 

XCodeGhost, the Apple malware that infected 50 applications within the Apple App Store 
was detected in September 2015. This malware was built into XCode, which made it harder 
to detect and was reported to affect more than 500 million users worldwide. Once detected, 
Apple immediately removed the infected applications. Currently, users can access the App 
Store via iTunes and also from their iOS devices. 


Jailbreaking 

Jailbreaking is the process of removing limitations imposed by Apple's mobile operating 
system through the use of software and hardware exploits. Jailbreaking permits unsigned 
code to run and gain root access on the operating system. The most common reason for 
jailbreaking is to expand the limited feature set imposed by Apple's App Store and to install 
unapproved apps. Jailbreaking can aid in forensic acquisition, but will void the user's 
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warranty, could "brick" the device and may not support being restored to the factory 
settings. 

O lf you jailbreak a device, it's best to assume that it will forever be 
jailbroken and the warranty is no longer valid. 

Many publicly available jailbreaking tools add an unofficial application installer to the 
device, such as Cydia, which allows users to install many third-party applications, tools, 
tweaks, and apps from an online file repository. The software downloaded from Cydia 
opens up endless possibilities on a device that a non-jailbroken device would never be able 
to do. The most popular jailbreaking tools are redsnOw, snOwbreeze, evasiOn, Absinthe, 
seasOnpass, Pangu, and TaiG. Not all iOS versions are jailbreakable. The website http : //w 
ww . guidemy j ailbreak . com/ choose-iphone-to- j ailbreak/ can be helpful to find out 
whether a particular iOS version is jailbreakable or not and with which method. In October 
2012, The U.S. Copyright Office declared that jailbreaking the iPad is illegal, while 
jailbreaking the iPhone is deemed legal. The governing law is reviewed every three years 
and has yet to be changed. 


Summary 

The first step in a forensic examination of an iOS device should be identifying the device 
model. The model of an iOS device can be used to help the examiner develop an 
understanding of the underlying components and capabilities of the device, which can be 
used to drive the methods for acquisition and examination. Legacy iOS devices should not 
be disregarded because they may surface as part of an investigation. Examiners must be 
aware of all iOS devices as old devices are sometimes still in use and may be tied to a 
criminal investigation. 

The next chapter will provide tools that will aid in obtaining data from iOS devices to later 
forensically examine. Not all tools are created equally, so it's important to understand the 
best tools to get the job done properly. 
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The examiner must not only know how to use forensic tools, but must understand the 
methods and acquisition techniques deployed by the tools they use in their investigations. 
Forensic tools not only save time but also make the process a lot easier. However, each tool 
has its flaws, and the examiner must catch mistakes and know how to correct them by 
leveraging another tool or technique. It's impossible for a tool to support all devices, and the 
examiner is responsible for learning and using the best tools to complete the job. As 
discussed in the last chapter, the examiner must understand how data is stored on iOS 
devices to ensure that the tool is capturing all accessible data. Without an expectation of 
what your forensic tool should extract, the examiner is limited and will be forced to rely 
solely on a tool. 

Currently, there are several commercial tools such as Elcomsoft iOS Forensic Toolkit, 
Cellebrite (UFED4PC, Touch, and Physical Analyzer), BlackLight, Oxygen Detective, 
AccessData MPE+, EnCase, iXAM, Lantern, MSAB XRY, and many more, which are 
available for forensic acquisition and analysis of iOS devices. For familiarity purposes, this 
chapter will walk you through the usage of a few commercial and open source tools and 
provide details of the steps required to perform acquisitions and analysis of iOS devices. 

In this chapter, we will cover the following topics: 

• Open source tools for forensic imaging of iOS devices 

• Commercial tools for forensic imaging of iOS devices 

• Errors that you may face along the way 


Working with Elcomsoft iOS Forensic Toolkit 

Elcomsoft iOS Forensic Toolkit (EIFT) is a set of tools aimed at making the acquisition of 
iOS devices easier. EIFT is a combination of software that is able to perform forensic 
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acquisition of iOS devices running any version of iOS (note that some iOS versions require 
the device to be jailbroken). Currently, EIFT is not capable of physically acquiring data from 
64-bit iOS devices (iPhone 6, 6s, and so on.). In order to get any data from a 64-bit iOS 
device, it must be jailbroken and the best acquisition will be a file system dump. For most 
other devices, EIFT can acquire bit-for-bit images of a device's file system, extract data 
including passcodes and passwords and decrypt the file system image. For more 
information on EIFT, visit http : / /www . elcomsoft . com/ eift . html. 

The toolkit was initially available only to law enforcement agencies, but now it is available 
to everyone. The toolkit supports both Mac OS X and Windows platforms with iTunes 10.6 
or later installed. 


Features of EIFT 

The following are the features of EIFT: 

• It supports physical and logical acquisition (physical access may require the 
device be unlocked or jailbroken) 

• The quick file system acquisition feature takes 20-40 minutes for 32 GB models 

• It supports passcode recovery attacks 

• It extracts device keys required to decrypt a raw disk image as well as keychain 
items 

• Decrypts a raw disk image and keychain items 

• The zero-footprint operation leaves no traces and alterations to device contents 

• Every step of investigation here is logged and recorded and is fully accountable 


Usage of EIFT 

EIFT can be used in two modes: the guided mode and the manual mode. The guided mode 
provides step-by-step instructions for those who are new to iOS device acquisitions or those 
who want options and instructions provided for each step during the extraction. The 
manual mode is for more advanced examiners who do not require step-by-step instructions. 
The USB dongle shipped with the toolkit must be connected to the computer while the 
toolkit is running. 


The guided mode 

The guided mode features a menu-based user interface where you can accomplish typical 
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tasks by selecting the corresponding menu items. You can start the guided mode by double- 
clicking on the Toolkit . cmd (Windows) or Toolkit . command (Mac OS X) file in the 
directory where you have copied the toolkit files. This should open the terminal window 
and present a text-based menu, as shown in the following screenshot: 



The Elcomsoft iOS Forensic Toolkit welcome screen 

When running in the guided mode, the toolkit logs all the activities to a text file. Each time 
the toolkit is started, a new log file is created in the user's home directory and the output of 
all the invoked commands as well as user choices are written to that file. 

To perform the physical acquisition of iPhone 4 and older devices with EIFT, follow these 
steps: 


1. Put the device in DFU mode. You can do this by selecting the menu item 1 and 
following the onscreen instructions. 
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2. After the device has been put in the DFU mode, load the ramdisk with the 

acquisition tools by selecting menu item 2 or answer Y to the prompt that follows 
the DFU procedure. It automatically detects the type of the device and loads the 
compatible ramdisk onto it. When ramdisk is successfully loaded, the device 
screen will display the Elcomsoft logo. 



The EIFT Ramdisk Instructions 

3. Recover the device passcode by selecting menu item 3. The toolkit can recover a 
simple 4-digit passcode in less than 20 minutes. It also provides options to 
perform dictionary (wordlist) and brute force attacks on complex passwords, as 
shown in the following screenshot: 
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\ C:\Windows\system32\cmd.exe 


Welcome to Elcomsoft iOS Forensic Toolkit 
This is driuer script version 2.0/UJin 

(c) 2011-2015 Elcomsoft Co. Ltd. 


I 


Please note that to recover passcode for iOS 4/5/6/7 deuice you need 
to load ramdisk on the iOS deuice first. If you hauen't done 
this yet, please return to preuious step and use corresponding menu 
item . 

Please choose the operation mode of passcode recovery: 

1 Only show passcode type 

2 Check 4-digit PINs 

3 Perform a wordlist attack 

4 Set custom passcode recovery parameters 

0 Back 

> : 


The El FT passcode recovery options 

4. From the Main menu, extract the encryption keys required to decrypt files and 
keychain items by selecting menu item 4. You will be prompted to supply the 
device passcode, if known, of the escrow file if you have access to the host 
computer and a filename to save the keys. If the filename is not supplied, the 
toolkit extracts the keys and stores it in the keys . plist file in the user's home 
directory. 
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The Elcomsoft iOS Forensic Toolkit Main Menu 

5. After extracting the keys, to decrypt the keychain items, select menu item 5. The 
toolkit uses the keys stored in the keys .plist file, decrypts the keychain items, 
and stores it in the keychain . txt file in the user's home directory. 

6. To acquire the physical image of the device's file system, select the menu item 6. 
You will be prompted to choose the device partition (system and user data) to 
image, as shown in the following screenshot: 
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SB C:\Windows\system32\cmd.exe 


□ 




Please select partition to image: 

1 System (rdiskOsIsl) — this one is NOT ENCRVPTED 

2 User (rdisk0s1s2) -- this one is ENCRVPTED 

0 Back 


Welcome to Elcomsoft iOS Forensic Toolkit 
This is driver script version 2.0/Uin for A5+ 

(c) 2O11-2015 Elcomsoft Co. Ltd. 


EIFT-selecting partition to image option 

After selecting the partition, the window prompts you for a filename to 

O save the image. If the filename is not supplied, it extracts the raw file 

system from the device and stores it as a user . dmg file in the user's home 
directory. Best practices include acquiring both the user and system 
partitions. 

7. After the acquisition, you can reboot the device to function normally by selecting 
menu item 9. 

8. To decrypt the acquired image, select menu item 7. You will be prompted to 
provide filenames of the encrypted image, device keys, and a filename to save the 
decrypted image. If the filename is not supplied, it decrypts the image and stores 
it as a user-decrypted . dmg file in the user's home directory. The toolkit also 
computes the SHA1 hash of the decrypted image file. EIFT is also capable of 
performing physical acquisition of a jailbroken iPhone 4S and newer devices 
running on iOS 5-9. 

9. EIFT requires the OpenSSH package to be installed on the device to perform 
acquisition on newer devices. OpenSSH runs the SSH server on the device and 
allows you to copy and run the acquisition tools. Once the SSH server is running 
on the device, you can follow steps 3 to 8 to acquire a raw disk image from an 
iPhone 4S and newer devices. 
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Should a device not be supported, an error message will appear during the device 
recognition phase of acquisition, as shown in the following screenshot: 



The Elcomsoft iOS Forensic Toolkit Acquisition Error Message 

Should this error appear, press Enter to return to the main menu and select another 
acquisition option. 


The manual mode 

The manual mode lets you interact with tools directly using the command-line interface. 
This mode allows greater flexibility and is recommended if you are comfortable with using 
command-line tools. The commands required to accomplish typical tasks in the manual 
mode are well documented in the technical guide that comes with the toolkit. 

The toolkit is capable of performing physical, file system, and logical acquisitions of the iOS 
device. But it does not provide options to analyze the acquired data and recover the deleted 
data. However, you can supply the . dmg file acquired with EIFT to Oxygen Forensics Suite, 
Cellebrite Physical Analyzer, Magnet IEF, and other tools for data analysis and recovery. 


EIFT-supported devices 

Elcomsoft iOS Forensic Toolkit Version 2.0 supports most iOS devices; however, some must 
be jailbroken. The following figure is taken directly from the help document that comes 
with the toolkit: 
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El FT supported devices 


Compatibility notes 

The following are the compatibilities of EIFT-supported devices: 

• Support for iPhone 4S and later versions is currently limited to jailbroken devices. 

• iOS versions older than 3.x store the device passcode in the keychain. On these 
devices, the passcode is recovered instantly during the encryption key and 
keychain data recovery. 

• Devices running iOS versions older than 3.x do not have data protection enabled 
and user partition is not encrypted. 
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Oxygen Forensic Detective 

Oxygen Forensic Detective is similar to Oxygen Forensic Suite, http : //www . oxygen-for 
ensic . com/en/, but it provides more advanced forensic software to extract and analyze 
data from cell phones, smartphones, PDAs, and other mobile devices. The software 
provides not only acquisition support, but also advanced application parsing and analysis 
support. Currently, Oxygen Forensic Detective Version 8.1 supports almost 12,000 different 
models of mobile devices. In addition to this, it offers support for 1,608 application versions, 
569 of which are parsed from iOS devices. 

Oxygen Forensic Detective uses proprietary low-level protocols to extract data from 
smartphones. Besides data extraction. Oxygen also gives you the opportunity to import a 
backup or image file obtained using other forensic tools, such as Cellebrite, Elcomsoft, XRY, 
iTunes, and open source tools for data analysis. It also stores the database of all the 
analyzed devices so that you can always view the previously extracted data. 

Oxygen Detective is available only for the Windows platform and requires iTunes to be 
installed on the computer. The software operates with original and jailbroken devices. It 
extracts the following data: phonebook with assigned photos, calendar events and notes, 
call logs, messages, camera snapshots, video and music, voice mail, passwords, dictionaries, 
geo-positioning data, Wi-Fi points with passwords and coordinates, IP connections, 
locations, navigation applications, device data, factory installed third-party applications 
data, and so on. It also recovers deleted data from SQLite databases. Oxygen Forensic 
Detective also parses Call Detail Records, Cloud data, and Event logs for additional 
analysis. For more information, visit http : / /www . oxygen-forensic . com/ en /products 
/ oxygen-forensic-detective. 


Features of Oxygen Forensic Detective 

The following are the features of Oxygen Forensic Suite: 

• It supports logical acquisition and file system and physical acquisition. Logical 
acquisition recovers the active files on the device. Deleted data may be obtained if 
the SQLite database is recovered. Physical and file system acquisition provide 
access to the raw file system data of the iOS device. 

• It supports password recovery from a keychain. 

• It enables Cloud data extraction and decryption. 

• It reads backup or images obtained using other forensic tools. 

• It provides rooting and jailbreaking assistance for devices. 

• The timeline provides a single-place access to all the user's activities and 
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movements arranged by date and time. 

• It supports aggregated contacts. This automatically combines accounts from 
different sources into one metacontact for each person. (Caution: Make sure that 
you know where the data is coming from! You should manually examine each 
file to ensure that nothing is overlooked and that the data is being reported 
correctly.) 

• It recovers deleted data automatically and provides the examiner with a tool to 
carve additional artifacts from SQLite databases. 

• It provides access to raw files for manual analysis. (Note that these are the raw 
database files associated with each application, they are not always the raw file 
system partitions.) 

• It provides an intuitive and user-friendly UI to browse through the extracted 
data. 

• It provides keyword lists and a regular expression library in order to search. 

• It supports report generation in several popular formats: Microsoft Excel, PDF, 
HTML, and so on. 


Usage of Oxygen Forensic Detective 

The acquisition of an iOS device is simple and straightforward with Oxygen Forensic 
Detective. The software helps you to connect a device in several mouse clicks and 
downloads all the available device information in just a few minutes for a logical 
acquisition. 

To perform the acquisition of an iOS device using Oxygen Forensic Extractor (the wizard 
that is used in Oxygen Forensic Detective), follow these steps: 

1. Launch Oxygen Forensic Detective and click on the Connect new device button. 
You will be prompted to choose the connection mode, as shown in the following 
screenshot: 
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Oxygen Forensic® Extractor v.8.1.0.105 


Oxygen Forensic® Extractor 

Oxygen Forensic® Extractor helps to connect and extract data from device. 




',©i Help 


Connection Mode 

[j§ Auto device connection 

Auto mode connects the first device detected on PC. 

Manual device selection 

Manual selection mode allows to choose connection type and device model 
from the list. 


Physical data acquisition 

MTK Android dump LG Android dump 

Samsung Android dump (via custom forensic recovery) 

No rooting is required. Lock screen is bypassed. 

The method may take a bit more time than physical dump via rooting. 

Disable screen lock 

Screen lock disabling for LG devices based on Android OS. To disable the lock it 
is required to have LG United Mobile Driver for LG devices. 

Screen lock disabling is performed via regular USB cable. 

Cancel 


Oxygen Forensic Extractor-the Connection Mode screen 

2. Connect the iOS device to the computer using a USB cable and choose the Auto 
device connection mode. It detects the connected device and displays the device 
information, as shown in the following screenshot. You can also manually choose 
your device. 
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0 


Oxygen Forensic® Extractor v.8.1.0.105 



Oxygen Forensic® Extractor 

Detection of devices connected via cable 



Connect device via cable 

Device is detected successfully! 

Press Next button to start extracting data from the device. Press Cancel if you do not 
need to investigate this device now. 


Device information: 



Model: 

IMEI: 

Software revision: 
Boot loader: 



Help 


Next > 

Cancel 


Oxygen Forensic Suite-the device information screen 

3. Click on Next. It prompts you to fill in the information about the device and the 
case. Continuing further, it prompts you to select the data types to be extracted 
from the device, as shown in the following screenshot: 

4. Again, click on Next. It extracts the data from the device and the process takes a 
few minutes depending on the amount of data stored on the device. Once the 
process is complete, the software displays a summary of the extracted data, as 
shown in the following screenshot: 
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- II Device Information 
® Aggregated Contacts 58 
‘I Phonebook 1 
Q Event Log 19 
-w Messages 4 


-*9 Timeline 538 


“HT1 File Browser 984 
O Passwords 50 
+ “ Organizer 

- P Dictionaries 

■ U. Web Connections 16 
-0 Links and Stats 

- v* Social Graph 
-CL Search 
-<x> Watch lists 

- ft Key Evidence 

- fe Reports 

©E3 Applications 67 
Cloud Accounts 


Oxygen Forensic Suite-the extracted data summary screen 

5. After the download process is complete, you can start your forensic examination. 

Working with Cellebrite UFED Physical 
Analyzer 

As per the vendor, Cellebrite UFED (Universal Forensic Extraction Device) empowers law 
enforcement, antiterrorism, and security organizations to capture critical forensic evidence 
from mobile phones, smartphones, PDAs, and portable handset varieties, including updates 
for newly released models. The tool enables forensically sound data extraction, decoding, 
and analysis techniques to obtain existing and deleted data from different mobile devices. 
As of March 2016, UFED supports data extraction from more than 18,000 mobile devices. 
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Cellebrite UFED Physical Analyzer can be used to perform physical and advanced logical 
acquisitions of iOS devices. Advanced logical acquisitions are the same as file system 
acquisitions in which access to the file system data is provided. Physical acquisition on iOS 
devices using the A5-A9 chips (iPhone 4s and newer) is not possible using this tool. Thus, 
the advanced logical acquisition method is the best support and will pull the most data 
from these devices if they are unlocked (even if they are not jailbroken). If the device is 
jailbroken, additional data can be extracted. Cellebrite Physical Analyzer is available only 
for Windows platforms. Cellebrite also offers a 30-day free trial for the software. 

For more information, visit http : / /cellebrite . com/Mobile-Forensi 
cs /Appl i cat i on s/u fed-physical -analyzer. 


Features of Cellebrite UFED Physical Analyzer 

The following are the features of Cellebrite UFED Physical Analyzer: 

• It supports physical and advanced logical acquisition (file system acquisition) 

• It extracts device keys required to decrypt raw disk images as well as keychain 
items 

• It decrypts raw disk images and keychain items 

• It reveals device passwords (not available for all locked devices) 

• It allows the examiner to open an encrypted raw disk image file with a known 
password 

• It supports passcode recovery attacks 

• It supports advanced analysis and decoding of extracted applications data 

• The platform provides access to physical and logical data extracted in the same 
user-interface, making analysis easier 

• It reports generation in several popular formats: Microsoft Excel, PDF, HTML, 
and more 

• Ability to dump the raw file system partition to import and examine it in another 
forensic tool 

• It creates a binary image file in addition to the . UFD shortcut file for ease of 
importing into other forensic tools for verification 
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Usage of Cellebrite UFED Physical Analyzer 

To perform the physical acquisition of iOS devices with UFED Physical Analyzer, follow the 
steps provided here. Note that physical acquisition is not supported for newer, non- 
jailbroken or 64 bit iOS devices (iPhone 4S and newer). 

1. Launch UFED Physical Analyzer and navigate to Extract I iOS Device 

Extraction. You will be prompted with the iOS device data extraction wizard, as 
shown in the following screenshot: 


Si i OS Device Extraction * * 

iOS Device Data Extraction Wizard 

Choose an extraction type: 


Advanced Logical extraction 


Physical mode 


Physical mode contains three types of extraction: 

• Physical extraction 

• File system extraction 

• Passcode recovery/test 

The device must be off. 

Supported devices running iOS 3.0 or higher: iPhone 
0 2G/3G/3GS/4, iPad 1, iPod Touch 1G/2G/3G/4G, 
iPod Nano 5G 






i 


UFED Physical Analyzer-the iOS device data extraction wizard screen 

2. Click on Physical mode. The first time you run iOS device extraction, you will be 
prompted to download and install the iOS support package. 
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3. Follow the instructions displayed on the screen to turn off the device and place it 
in recovery mode. Once the tool detects the device in recovery mode, it displays 
the device information, as shown in the following figure: 


ill iOS Physical 

1- |»*-j 

| Successfully entered Recovery Mode. 




Connect > Prepare > Extract data 

You can release the Home button now. 

Device Info: 


copy 


Device model: 
iOS version: 
Serial number: 
ECID: 

Board: 


iPhone 4 GSM 
7.0.3-7.0.4 

OOOML-H 

n90ap 

iBoot firmware version: iBoot-1940.3.5 
Chip ID: 8930 



Next 


UFED Physical Analyzer-the device information screen 
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You may find that your device is unsupported as shown in the following 
figure: 


|Jj iOS Physical 4.2 




k 


rry, but the device you connected is currently unsupported. 


Connects Prepares Extract data 


You can release the Home button now. 

Device Info: 


Device model: 
iOS version: 

Serial number: 

ECID: 

Board: 

iBoot firmware version: 
Chip ID: 


iPhone6 

8.3 

dnpb 

001EI ■ M 
n61 

iBoot-2261.20.20 

7000 



UFED Physical Analyzer - Unsupported device-the device information screen 

4. Should the device be unsupported, click on Exit and attempt an Advanced 
Logical Extraction. 

5. If supported, click on Next and put the device in DFU mode. When the device is 
detected in DFU mode, the software loads the acquisition tools onto the device. 

6. Once the device is ready for extraction, you will be prompted to choose the 
desired extraction type (Physical Extraction or File System Extraction). Click 
on Physical Extraction and choose the User and System data partitions and the 
location where you want to save the extraction. 

7. If prompted, continue further and click on Recover the passcode for me to 
recover the passcode prior to the extraction. Complex passcode attempts are 
possible, but require manual attacks. 
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8. If the device is newer than the iPhone 4s or when Physical Extraction is not 
supported, click on Advanced Logical Extraction. For normal iOS devices, two 
methods of extraction are offered. It is recommended to use both methods to 
ensure that most data is extracted. 



UFED Physical Analyzer - Advanced Logical Extraction Options 

9. For jailbroken iOS devices, an additional extraction method is offered. Best 

practices state to capture all data using each method and then merge the data into 
one instance of Physical Analyzer to ensure that all data is examined. 
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UFED Physical Analyzer - Advanced Logical Extraction Options - Jailbroken Devices 

10. With all of the methods above, once the selections are made, select Continue. The 
tool extracts the file system image and decrypts it when you select to Open in 
UFED Physical Analyzer. 


Supported devices 

The UFED Physical Analyzer version 5.0 supported iOS devices are shown in the following 
table (note that these devices may be required to be unlocked): 


Model 

iOS version 

Physical acquisition 

Advanced logical 
acquisition 

iPhone, iPhone 3G, iPod Touch 1, 2 

iOS 1/2/3/4 

Yes 

Yes 
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iPhone 3GS, iPod Touch 3, iPad 1 

iOS 3/4/5 

Yes 

Yes 

iPhone 4, iPod Touch 4 

iOS 4/5/6/7 

Yes 

Yes 

iPhone 4S, 5, 5C, 5S, 6, 6 Plus, 6S 
and 6S Plus iPad 2, 3, 4, iPad mini 
2,3,4, iPad Air 2, iPad Pro 

iOS 5/6/7/8/9 

No (unless jailbroken 
32-bit device) 

Yes 


UFED Physical Analyzer - supported devices 


Working with BlackLight 

BlackLight, a tool offered by BlackBag Foreniscs, provides support for mobile devices. 
BlackBag is known for their effective support for Apple products, including iOS devices. 
Currently, BlackLight offers support for parsing images created using other tools, encrypted 
and non-encrypted backup files and by connecting the device to the forensic workstation 
via USB. If the device is jailbroken, additional data can be extracted. BlackLight is available 
for Macintosh and Windows platforms. BlackLight also offers a 30-day free trial for the 
software and, often, free training. For more information, visit https : //www.blackbagtec 
h . com/ sof t ware -product s /black light- 6 /black light . html. 


Features of BlackLight 

The following are the features of BlackLight: 

• It supports parsing for most acquisitions of iOS devices and backup files 

• It provides decryption options 

• It provides advanced filtering options for analysis 

• It provides insight to recently used applications and accessed files 

• It provides a method for a triage view of devices connected via USB 

• It often recovers artifacts from hex that other tools miss 

Usage of BlackLight 

Blacklight is known for Apple support and can be used to triage attached devices via USB, 
load iOS device acquisitions, and the analyse data for attached devices. Simply selecting the 
Add button presents the examiner with options for acquiring and analyzing data. These 
details are covered in the following steps: 
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1. Create a case using the Wizard once BlackLight is launched. 

2. Select Add and select the method for which an evidence or a device will be 
introduced to the tool. Options include connecting a live device via USB for quick 
extraction and analysis, adding a backup file or previously acquired image. Other 
tool images are supported. 


ri» BlackLight Case.BlackLight 


File Edit Action Tags View Manage Wi 



Case Info Timeline Search Re 



B EVIDENCE 
B ACTIVITY 

♦ Export Status 
■ Evidence Status 
B CONTENT SEARCHES 
B TAGS 


Examiner Infori 


Name: 

1 

Title: 

Address: 


Phone: 



BlackLight - Adding Evidence to a Case File 

3. In this example, we are going to examine an attached iPhone connected via USB. 

4. Select Add USB Attached Mobile Device. The following screen will appear 
allowing the examiner to select the methods for extracting data from the attached 
device. 
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Evidence S election: 
Device Name 
iPhone of H 

Offline 


UDID Evidence ID 

44bf2e5198c5fb077blb77562e55482ealb25d0e <Clickto Edit> 

emulator-5554 


Mobile Device Import Options 

W\ Applications g Photos 0 Media 

(iOS: Full Bundle Data, Android: Install BB (Non synced pictures) (Mus fK Movies) 

The import options will pull more data but will take significantly to process. 



Processing Options 


Presets: Comprehensive (Slow - Full Processing) 


File Analysis: 0 Signature Analysis 0 Process Pictures 0 Process Videos 

File Hashes: 0MD5 0SHA1 0SHA256 

0 Identify Known Files Settings... I 


Unallocated Space: _ Locate Files 


Settings... 


These processing options can be run later from the Evidence Status screen. 


Cancel 1 Add 


BlackLight - Selecting the processing method 
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5. Once BlackLight has extracted the data, a summary will be provided and analysis 
can ensue. 



BlackLight - parsed data for analysis 


Open source or free methods 

Several methods are available to acquire and analyze iOS devices for free. Most of these 
tools have been built by practitioners in mobile forensics who recognize the need for 
affordable solutions that work to obtain the same amount of data as commercial kits. Jon 
Zdziarski has developed several scripts, tools, and methods to acquire data from iOS 
devices. Some of his methods such as physical acquisition scripts are restricted to law 
enforcement, and unfortunately, they do not work on newer devices. Zdziarksi released his 
instructions to acquire data from iOS devices and this can be read at 

http : / / www .zdziarski. com/blog/ wp-content /up loads/ 2013/05/ iOS-Forensic-I 
nvestigative-Methods .pdf. 


[ 78 ] 


iOS Forensic Tools 


For those who cannot afford the tools defined earlier in this chapter, there are other tools 
that exist so that you can acquire and analyze iOS device images and backup files. Some of 
these tools simply provide access to the logical file system or create a backup file and 
include iFunBox, iExplorer, iBackupBot, and more. Make sure that you test these tools 
before relying on them for a forensic investigation. Again, they are either free or request a 
donation for use. They are developed by the community for examiners to use. They often do 
not go through rigorous amounts of testing and validation and may miss data that can be 
manually extracted by the examiner. It is the examiner's responsibility to learn the tool, test 
it, and know its flaws in order to recover all of the available data. 

If your hope is to obtain a forensic acquisition, tools such as Magnet Acquire and 
NowSecureCE can be used. Depending on the device (model, iOS version), and whether or 
not it is locked and/or jailbroken, the methods for extraction may be limited. Our best 
advice is to try these tools, because you may be surprised at how much data you can obtain 
from an iOS device for free. 


Working with Magnet ACQUIRE 

Magnet ACQUIRE, or Magnet Community Edition, was designed by Magnet Forensics for 
the community of examiners who do not have a large budget to purchase acquisition tools. 
This tool will acquire data from both iOS and Android devices. For more information, visit 

http : / / www . magnet forensics . com/ digit al-f orensics-software/magnet-acquir 

e. 


Features of Magnet ACQUIRE 

The following are the features of Magnet ACQUIRE: 

• It supports iOS and Android device acquisition 

• Fast acquisition providing access to data for a triage examination 

• It has well-documented acquisition methods that are saved into an activity log 
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Usage of Magnet ACQUIRE 

Magnet ACQUIRE provides a free and easy solution for acquiring mobile devices. The 
following points demonstrate how Magnet ACQUIRE is to be used: 

1. Launch Magnet ACQUIRE. 

2. If your device is recognized, simply select that device. If not, select The device 
I'm looking for isn't showing up for additional troubleshooting instructions. 


@ Magnet ACQUIRE 





CHOOSE YOUR DEVICE 


'O' 


©: 


ANDROID 


DRIVE 


<3 


iOS 


An Android device was detected 

To allow USB debugging on the device, please select "Always allow this computer" and click OK. 

Name PhysicalDrivel WIBU - CodeMeter-Stick USB Device (39.25 MB) 

Type External hard disk media 
Size 39.25 MB 
Serial Number 

Model iPhone7,2 
OS 83 
Color Silver 
Privileged access Yes 


The device I'm looking for isn't showing up 


PROVIDE FEEDBACK 


Magnet Acquire - Device recognition 


3. Once the device of interest is detected and selected, click on Next. 

4. All acquisition methods available for that device will be listed. Wherever 
possible, select Full, as this will capture the most data from the device. 
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[jj Magnet ACQUIRE 


= (Hi X 


OPTIONS 


SELECT IMAGE TYPE 



APPLE iPhone7,2 
OS version: 8.3 
Privileged access 


Please select the type of image you want to acquire: 

Full 

@ All files and folders More info 

Quick 

® Native and 3rd party application data, media More info 


PROVIDE FEEDBACK 


BACK 


NEXT 


Magnet ACQUIRE - Acquisition options 


5. Click on Next. 

6. The acquisition will start as shown in the following image: 
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OPTIONS 


CREATING FULL IMAGE 


Full imaging in progress.. 

Elapsed time: 0 hours 7 minutes 


APPLE iPhone7,2 
OS version: 8.3 

Privileged access Running AFC2 service... Successful 

Building image... In Progress 



PROVIDE FEEDBACK 


BACK 




Magnet ACQUIRE - Acquisition in progress 

7. Once complete, the acquisition can be imported into a tool for analysis. 

8. Some devices are not supported by Magnet Acquire. An example of a non- 
jailbroken iPhone 6s, running iOS 9.2 is shown in the following screenshot. Note 
that no support is provided. 


[ 82 ] 




iOS Forensic Tools 



Working with NowSecureCE 

NowSecure offers a free acquisition tool for everyone to use. This tool, NowSecureCE, 
previously known as ViaExtractCE, provides support for file system, logical, and backup 
file acquisitions of iOS and Android devices. The tool currently exists within a provided 
virtual machine, but this may change with future releases. For more information, visit http 
s : / /www. nowsecure . com/ forensics/. 


Features of NowSecureCE 

The following are the features of NowSecureCE: 

• It supports file system, logical, and backup extractions for iOS and Android 
devices 

• It recovers calls, SMS, contacts, and more 

[ 83 ] 


ww w . allitebooks .com 





iOS Forensic Tools 


• It provides methods for obtaining root access on Android devices 

• It supports parsing Android and iOS backup files 


Usage of NowSecureCE 

NowSecure CE supports Android and iOS files and is easy to use, once you get the VM up 
and running. The following steps will guide you through the recommended steps for 
acquiring iOS devices: 

1. Once the VM is launched, select NowSecure. 

2. Next, select New to create a new project. 


© 

Create a project 

New Project - + x 

Result 

Type ® Forensic Case ▼ 


Name Heather's iPhone 


Cancel Continue 


Now Secure - Creating a case file 

3. Select Continue and Close when the case is created. 

4. The device must be passed through to the VM from the host machine or the 
device will not be recognized. Navigate to VM I Removableor USB devices and 
select the correct device and elect to connect it. 



Depending on your virtual player or machine, you may have different 
options for passing a device from the host computer to the NowSecureCE 


VM. 


5. Once connected, you may have to select Trust Computer on the iOS device. 
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NowSecure CE will show the device information as well as the acquisition support for that 
device. (Note that a full license may be required to acquire newer iOS devices, as shown in 
the following screenshot): 


(f) New Report jjg| Location |||| Timeline C\ Search 


B Device Info 

i Device Information 


aa □ 

c m ■ 

Bin 


^ m D ' 


Properties 

Manufacturer Apple 

Model iPhone 6 
OS iOS 8.3 

Serial number DNPPNYC3C5MD 
IMEI/MEID 359231067814614 

Jailbroken -s 


0 Rescan device 

Extraction Options 

y iOS Logical Extraction [Full version only] 


Logical extraction of core and 3rd-party app artifacts 

$Root Device 


0 Extract 


Olmport 



Now Secure - Acquiring an iOS device 

After the data is extracted, analysis can be completed within the NowSecure VM. 
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Summary 

Forensic tools are helpful for an examiner as they not only save time but also make the 
process a lot easier. However, not everyone has a budget large enough to purchase 
commercial tools to obtain iOS acquisition. While free tools exist for acquisition, support 
may be limited and multiple extractions may be required to obtain the same amount of data 
as a commercial tool. 

For jailbroken devices, the iOS device could be connected to a Mac for live examination via 
SSH, which is how some of the tools acquire the data. However, this is not a method that is 
recommended for those new to digital forensics. For such purposes, this chapter introduced 
you to several available iOS forensic tools and included the steps to perform acquisition of 
an iOS device. 

Examiners should take further steps to validate and understand each tool that might be 
used as part of an investigation. We recommend acquiring test devices with known data to 
ensure nothing is overlooked, evidence is not altered and the methods provide the 
examiner with access to the data of interest, where possible. 

In the next chapter, we will dive into acquiring data from iOS devices, how to bypass 
locked devices, and what to expect with Apple encryption. 
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An iOS device recovered from a crime scene can be a rich source of evidence. Think about 
how personal a smartphone is to a user. Nothing else digital comes close. We rarely leave 
our homes or even walk around our homes without our smartphones within arm's reach. It 
is literally a glimpse of the most personal aspects of a human, almost like a diary of our 
everyday activity. According to several news references, Ocsar Pistorius' iPads were 
examined by a mobile expert and presented during the murder trial to show Internet 
activity hours before the murder of his girlfriend. When an iOS device can provide access to 
the so-called "smoking gun," the examiner must ensure that they know how to properly 
handle, acquire, and analyze the device. 

There are different ways to acquire forensic data from an iOS device. Though each method 
will have its positives and negatives, the fundamental principle of any acquisition method 
is to obtain a bit-by-bit or physical copy of the original data, where possible. With newer 
iOS devices, this is almost impossible. 

In this chapter, we will cover the different methods of acquisition for iOS devices to include 
the following: 

• iOS device operating modes 

• Physical acquisition 

• File system acquisition 

• Logical acquisition 

• Acquiring jailbroken devices 

• Password protection and potential bypasses 



Data Acquisition from iOS Devices 


While the ultimate goal in a forensic examination is to obtain the physical image, this is not 
possible for all iOS devices, so we need to understand the next best option when our 
primary goal is not possible or supported by our tools. 


Operating modes of iOS devices 

Before we dive into the forensic techniques and acquisition methods, it is important to 
know the different operating modes of an iOS device. Many forensic tools and methods 
require you to place the device into one of the operating modes. Understanding the iOS 
device operating modes is required in order to perform a particular action on the device. 
While most commercial tools will demonstrate the proper steps to get the device into a 
particular mode, the examiner must understand what that mode represents. iOS devices are 
capable of running in different operating modes: the normal mode, recovery mode, and the 
DFU mode. Some forensic tools require the examiner to know which mode the device is 
currently utilizing. We will define each mode in this section. 

Note that when the term "iPhone" is mentioned, it should be understood 
that the statement remains true for all iOS devices. 


The normal mode 

When an iPhone is switched on, it is booted to its operating system; this mode is known as 
the normal mode. Most regular activities (calling, texting, and so on) performed on an 
iPhone will be run in the normal mode. 

When an iPhone is turned on, internally, it goes through a secure boot chain, as shown in 
the following figure. This does not occur for jailbroken devices. Each step in the boot-up 
process contains software components that are cryptographically signed by Apple to ensure 
integrity. 
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A secure boot chain of an iPhone in normal mode 

The Boot ROM, known as the secure ROM, is read-only memory (ROM) and is the first 
significant code that runs on an iPhone (http : //images . apple . com/ ipad/business/do 
cs/iOS_Security_Febl4 .pdf). An explanation of the boot process for iOS devices are is 
defined in the following steps: 

1. The Boot ROM code contains the Apple root CA public key, which is used to 
verify the signature of the next stage before allowing it to load. 

2. When the iPhone is started, the application processor executes the code from the 
Boot ROM. 

3. The Boot ROM, in turn, verifies whether the Low Level Bootloader (LLB) is 
signed by Apple or not, and loads it. 

4. When LLB finishes its tasks, it verifies and loads the second stage boot loader 
(iBoot). iBoot verifies and loads the iOS kernel. 

5. The iOS kernel, in turn, verifies and runs all the user applications, as shown in 
the preceding figure. 

6. The secure boot chain ensures that iOS runs only on validated Apple devices. 
When an iOS device is in this state, it is possible to gain everything that is 
accessible to the user through forensic acquisition. Most often, this includes a file 
system or logical acquisition, which will be discussed later in this chapter. 


The recovery mode 

During the boot-up process, if one step is unable to load or verify the next step, then the 
boot-up is stopped and the iPhone displays a screen, as shown in the following screenshot. 
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This mode is known as the recovery mode. The recovery mode is required to perform 
upgrades or to restore the iPhone. 

To enter the recovery mode, perform the following steps: 

1. Turn off the device— press and hold down the Sleep/Power button located at the 
top of the iPhone until the red slider appears. Then, move the slider and wait for 
the device to turn off. 

2. Hold down the iPhone Home button and connect the device to a computer via a 
USB cable. The device should turn on. 

3. Continue holding the Home button until the Connect to iTunes screen appears, 
as shown in the following screenshot. Then, you can release the Home button. 
(On a jailbroken iOS device, this screen may appear with different icons.) Most 
forensic tools and extraction methods will alert the examiner about the current 
state of the iOS device. 

O On older iOS devices, the iTunes Icon will be blue and the cable will reflect 
the original Apple cable. 


® 

iTunes 

I 


iOS device recovery mode 
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O You can read more about the iOS device recovery mode at http : //suppo 
rt . apple . com/kb/HT1808. 

4. To exit the recovery mode, reboot the iPhone. This can be completed by holding 
the Home and Sleep/Power button until the Apple logo appears. 

Normally, the process of rebooting returns the iPhone from recovery mode to normal mode. 
This same methodology applies to the Apple Watch. The examiner may experience a 
situation where the iPhone constantly reboots into the recovery mode. This is known as a 
recovery loop. A recovery loop may occur when the user or examiner attempts to jailbreak 
the iOS device and an error occurs. To get the device out of a recovery loop, the device must 
be plugged into iTunes and a backup is restored to the device. 

This makes changes to the evidence, so ensure that you have validated 
your acquisition methods on a test device prior to attempting methods on 
real evidence. 

For older devices, exiting a recovery loop was a much easier on both Windows and Mac 
computers. For older devices, several open source methods exist to repair a recovery loop. 

The following steps show the redsnOw tool used on a Mac, which can be used to exit a 
recovery loop: 

1. You can download the latest version of redsnOw at https : //sites . google . co 
m/a/ iphone-dev . com/ files/. 

2. Then, navigate to Extras I Recoveryfix, as shown in the following screenshot. An 
external method or tool may not be required. Sometimes, placing the device in 
the DFU mode and connecting the device to iTunes will properly reboot the 
iPhone. 
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redsnOw 0.9.15b3 


Welcome! This is the latest version of redsnOw. 

Copyright 2007-2012 iPhone Dev-Team. All rights reserved. Not 
for commercial use. 

For support, visit our blog or try searching lailbreakQA. 


Extras 


lust boot | Just boot tethered right now. 


Pwned DFU Enter pwned DFU mode in preparation for 
restoring to a custom IPSW. 

Recovery fix C t out of Recovery Mode loop caused by a 
re tore error. 


SHSH blobs Fetch, verify or use SHSH blobs. 


Select IPSW j 

Custom IPSW 

Even more 


Manually specify an IPSW. 

Preserve baseband with a custom IPSW. 

Device info, IPSW restores, and more. 


< Back Quit 


The redsnOw recovery fix 


DFU mode 

During the boot-up process, if the Boot ROM is not able to load or verify the LLB, then the 
iPhone displays a black screen. This mode is known as Device Firmware Upgrade (DFU) 
mode. DFU mode is a low-level diagnostic mode and is designed to perform firmware 
upgrades for the iPhone. During a firmware upgrade, the iPhone goes through a different 
boot sequence, as shown in the following figure. Most forensic tools use DFU mode to 
perform a physical acquisition. 
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Boot ROM (DFU) 
i 



A secure boot chain of an iPhone in DFU mode 

In DFU mode, the Boot ROM boots first, which, in turn, verifies and runs the second stage 
boot loaders, iBSS, and iBEC. iBSS is a modified version of iBoot which kicks off the iBEC 
loader, verifies, and loads the kernel (https : / /www.theiphonewiki . com/wiki/IBSS). 
The kernel verifies and loads the ramdisk into memory. Again, most forensic acquisition 
methods require the iOS device to successfully enter DFU mode. As mentioned in Chapter 
1, Introduction to Mobile Forensics, all steps must be well documented by the examiner. The 
handling of the iOS device is no exception. DFU mode is a method recognized in mobile 
device forensics and is deemed to be a forensically sound action to prepare the device for 
forensic acquisition. 

To enter DFU mode, perform the following steps: 

1. Download and install iTunes on your forensic workstation from http : / /www . ap 
pie . com/itunes/download/. Make sure that you have the latest version and 
that it is forensically sterile to prevent cross-contamination across evidence 
plugged into the workstation. Connect your device to the forensic workstation 
via a USB cable. 

2. Turn off the device. 

3. Hold down the Power button for 3 seconds. 

4. Hold down the Home button without releasing the Power button for exactly 10 
seconds. 

5. Release the Power button and continue to hold down the Home button until you 
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are alerted by iTunes with the iTunes has detected an iPhone in recovery mode. 
You must restore the iPhone before it can be used with iTunes message. 

At this point, the iPhone screen will be black and should not display anything. The iPhone 
is ready to be used in DFU mode. If you see the Apple logo or other signals that the device 
is booting, repeat steps 2 through 5 until iTunes displays that message. 

Most forensic tools running on a Windows platform will provide these instructions, with 
graphics, as shown in the following screenshot. This figures shows UFED Physical Analyzer 
being used to physically acquire an iOS device: 


Prepare the device for physical extraction 


Connect > Prepare > Extract data 

The device needs to be in DFU mode (Device Firmware Update) to enable data extraction. 



Press and hold both the When the device screen 

Power and Flome buttons. turns black, wait 3 seconds. 



Release only the power 
button. Keep holding the 
home button. 


< Back 


UFED Physical Analyzer explains how to place a device into DFU-mode 

To verify whether the iPhone is in DFU mode on Mac OS X, launch System Information 
and go to the USB option. You should see a device similar to what is shown in the 
following screenshot: 
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« n n 

Mar8ool< Pro 


▼ Hardware 

USB Device Tree 

a 

ATA 

USB 3.0 M Speed Bus 


Audio 

USB 3.0 supersoeed Bjs 


Bluetooth 

▼USB HI 5 peed Bus 


Camera 

▼ Hub 


Cat a Readei 

Apple Mobile Device (DFU Mode) 


Diagnostics 

▼Hub 


Di*c Bu 'ning 

IR Receiver 


Ethernet Card* 

v 3RCM2O702 Hub 


Fibre Channel 

Bluetooth USB host Ctyitiollet 


FtreWire 

Await Internal Keyboard > Trackpad 


Graphic* /Display* 

▼USB Mi-Speed Bus 


Hardware RAID 

▼Hub 


Memory 

FaceTime HD Camera (Suite- in) 


PC! Card* 



Paral lei SCSI 

Apple Mobile Device (Dru Mode): 


Power 

Product iD. 0x1227 


Printer* 

Vendor id: OxQSac (Apple me. l 


SAS 

Vers, on- 0 00 


SATA; SATAExpre** 

5PI 

Storage 

Thunderbolt 

Serial Number CPID 8930 CPRV 20 CPFS' 03 SCCP01 BDI0 00 CCID 00000 1C3 1U0CDBC IBFl 00 

S RTC:[i Boot-5 74.4 1 

Speed: Up to 4BD Mb; sec 

Manufacturer Apple Inc 

location ID OxldllOOOO/8 

USB 

Current Awa lable (mA) 500 

Current Required (mA). 100 


▼ Network 


Firewall 

Locations 

Modems 

Volumes 

WWAN 



M Mac • Hardware • USB 

USB Hi-soeed Bus • Muo Apple Mobile Device (DFU Mode) 



The MAC system information displaying a DFU-mode device 

Just like in recovery mode, to exit DFU mode, hold down the Home button and the Power 
button until the Apple logo appears on the device. 

O More information can be found on methods to verify DFU mode at http : 

//www .zdziarski. com/blog/wp- content /uploads/ 2013/ 05/iOS-F 
orensic- Investigative-Methods . pdf. 

Pulling the cable during acquisition while the device is in DFU mode will not harm the 
device. Most tools will alert the examiner to not disconnect the device. However, in certain 
situations, such as covert or undercover operations, a device may have to be unplugged 
abruptly. If this is something you are faced with, rest assured that the device will not be 
damaged, but it is unlikely that you will obtain a forensic image that you can later examine. 
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Setting up the forensic environment 

The first edition of Practical Mobile Forensics included several methods of performing iOS 
device forensics on a Mac. This book incorporates methods for performing acquisition on a 
Windows system as well as a Mac. Most of the forensic tools supported by Windows and 
Mac platforms leverage iTunes during the acquisition process. In order to prevent cross- 
contamination of data, a fresh installation of iTunes should be used for every investigation. 
It is recommended that you install the software recommended by your tools to ensure that 
you don't cause device conflicts on the PC. 

You will find that few tools work on both Mac and Windows platforms. Most examiners 
select the platform and then branch into the tools that provide the best support. Some will 
say that you should always examine an iOS device using a Mac; however, some of the most 
robust smartphone tools run on the Windows platform. 


Physical acquisition 

iOS devices have two types of memory: volatile (RAM) and non-volatile (NAND Flash). 
RAM is used to load and execute the key parts of the operating system or the application. 
The data stored on the RAM is lost after a device reboots. RAM usually contains very 
important application information, such as active applications, usernames, passwords, and 
encryption keys. Though the information stored in the RAM can be crucial in an 
investigation, currently there is no easy method or tool available to acquire the RAM 
memory from a live iPhone. 

Unlike RAM, NAND is non-volatile memory and retains the data stored in it even after a 
device reboots. NAND flash is the main storage area and contains the system files and user 
data (http : / / nvlpubs . nist . gov/ nistpubs/SpecialPubli cat ions /NIST . SP . 800-1 
0 Irl . pdf). This document, written by NIST, not only covers memory storage in mobile 
devices, but mobile device forensic practices in general. 

The goal of physical acquisition is to perform a bit-by-bit copy of the NAND memory, 
similar to the way in which a computer hard drive would be forensically acquired. While 
data storage seems similar, NAND differs from the magnetic media found in modern hard 
drives. NAND memory is cheaper, faster, and holds a great amount of data. Thus, NAND is 
the ideal storage for mobile devices as mentioned in Learning iOS Forensics, Mattia Epifani 
and Pasquale Stiparo, Packt Publishing. 

Physical acquisition has the greatest potential for recovering data from iOS devices; 
however, current and evolving security features (secure boot chain, storage encryption, and 
passcode) on these devices may hinder the accessibility of the data during forensic 
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acquisition. Researchers and commercial forensic tool vendors are continually attempting 
new techniques to bypass the security features and perform physical acquisition on iOS 
devices. The methods allowing physical access to iOS devices are discussed in the following 
section. 


Physical acquisition via a custom ramdisk 

Acquisition via a custom ramdisk is a novel method to acquire data from an iPhone. By 
exploiting a weakness in the boot process while the device is in DFU mode, it loads a 
custom ramdisk and then gets access to the file system. A custom ramdisk contains the 
forensic tools necessary to dump the file system over USB via an SSH tunnel. If done 
correctly, loading a custom ramdisk onto a device will not alter the user data, and thus the 
evidence will not be destroyed. 

Imagine a computer that is protected with an OS-level password; we can still access the 
hard disk contents by booting with a live CD. Similarly, on the iPhone, we can load a 
custom ramdisk over USB and access the file system. However, the iPhone secure boot 
chain may prevent us from loading the custom ramdisk. We can achieve this by exploiting a 
Boot ROM vulnerability and patching successive stages, as shown in the following figure: 


Pwned Boot ROM (DFU) 
I 



An exploited boot chain of an iPhone in DFU mode 
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Hacker communities have found several Boot ROM vulnerabilities in A4 devices (iPhone 4 
and older iPhone models). Currently, there are possible vulnerabilities that may provide 
access to A5-A7 devices, but there is no guarantee. Currently, A8 and later devices prove to 
be the most difficult in detecting vulnerabilities or methods to physically access the device. 
The state (jailbroken or not), the model, and OS version all play a role in determining 
accessibility. Boot ROM vulnerabilities cannot be fixed with software updates, effectively 
making a device vulnerable forever. 

Smartphone forensic tools leverage these vulnerabilities as a method to physically access 
iOS devices. Tools such as Elcomsoft, MSAB, and Cellebrite that offer physical acquisition 
support often show the examiner the process of loading the custom Boot ROM onto the iOS 
device. This takes the guesswork out of the equation as the steps are simple to follow. As 
we will explain now, UFED Physical Analyzer instructs the examiner to carry out the 
required steps to place the device into DFU mode. From there, the tool will alert the 
examiner if the device is supported for physical acquisition or if another method must be 
used to acquire data from the device. 

It is recommended that the examiner attempt physical acquisition regardless of the 
advertised support by the tool because we never know the true state of the device (for 
example, jailbroken or not) and we just might get lucky. 


g| iOS Physical 4.2 


* 


ccessfully entered DFU Mode 


Connect > Prepare > Extract data 

You can release the Home button now. 


The wizard is now uploading the forensic program to the device. This will take about a minute. 
Stage 7 out of 24: Uploading bootloader file (iBSS) 



Total Progress: 16% 



Custom Bootloader being uploaded to an iPhone 4 
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Imaging the user and system partitions 

As discussed in Chapter 2, Understanding the Internals ofiOS Devices, NAND flash on iOS 
devices contains two logical disk partitions: system partition and user data partition. On a 
non-jailbroken device, the system partition will be kept in the read-only format. The user 
data partition contains all the user-installed applications and data. 

For full forensic analysis, it is preferred that both the system and user partition are acquired. 
Most forensic tools will capture both partitions in one image. If the examiner has a time 
crunch, at the minimum, they should dump the entire data (user) partition. To acquire a 
full-disk image, both the data and system partitions should be selected, as shown in the 
following figure: 



Physical acquisition of the system and user partitions by UFED Physical Analyzer 
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Other forensic tools provide physical acquisition access similar to the provided examples 
above, as described in Chapter 3, iOS Forensic Tools. Our best is advice is to ensure that 
you have tested and validated your forensic tool of choice prior to using it to conduct a 
forensic acquisition. 


Encrypted file systems 

In addition to the acquisition hurdles, the file system on the iPhone is encrypted. Since the 
release of the iPhone 3GS, the hardware and firmware encryption are built into iOS devices. 
Every iOS device has a dedicated AES 256-bit crypto engine (the AES cryptographic 
accelerator) with two hardcoded keys: UID (Unique ID) and GID (Group ID) (as stated by 
Zdziarski). The CPU on the device cannot read the hardcoded keys but can use them for 
encryption and decryption through the AES accelerator. The UID key is unique for each 
device and is used to create device-specific keys (the 0x835 key and the 0x8 9B key) that are 
later used for file system encryption. The UID allows data to be cryptographically tied to a 
particular device; so, even if the flash chip is moved from one device to other, the files are 
not readable and remain encrypted. The GID key is shared by all devices with the same 
application processor (for example, all devices that use the A 7 chip) and is used to decrypt 
the iOS firmware images (IPSW) during installation, restore, and update. The GID prevents 
hackers from reversing the firmware and finding security vulnerabilities. 

Apart from the UID and GID, all other cryptographic keys are created by the system's 
random number generator (RNG) using an algorithm based on Yarrow. 

More information on encryption and Yarrow-based algorithms can be 
found at http: / /www. apple . com/business/docs/ iOS_Security_Gu 
ide . pdf. 

When this method of access is granted, we get a plethora of data from the iOS device. The 
following is an example of UFED Physical Analyzer prompting the user to select the type of 
acquisition they wish to perform on the device. Where possible, always get a physical image 
of an iOS device first and then follow with a file system and logical. Why, you may ask? 
Because each acquisition method provides us access with varying amounts of information. 
Only the most well-trained examiners will uncover all data from a physical acquisition 
without the help of a file system and logical acquisition report to guide their investigative 
path. Best practices say to grab a physical acquisition first. Unfortunately, this is rarely an 
option with modern iOS devices. 
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loose an extraction method 


Connect > Prepare > Extract data 

The device (iPhone 4 CDMA with iOS 6.1-6. 1.6) is encrypted and protected with a simple passcode. All data can be fully 
extracted and decrypted in UFED Physical Analyzer. The passcode can be recovered automatically, if you don't know the 
passcode. 


Physical Extraction 


l=j|. File System Extraction 


[ • Passcode recovery 


Extraction and Encryption FAQ 


Extract a physical image of the device's storage memory to your computer. 


Extract all files from the device to your computer. 


Recover the passcode so you can unlock and use the device. 


| Turn off the device and exit^ 


Physical Extraction as offered by UFED Physical Analyzer 


File system acquisition 

The term file system acquisition was first introduced by Cellebrite, but has since been 
adopted by other commercial forensic tools and is sometime referred to as advanced logical 
acquisition. This method of acquisition enables the examiner to gain more data than 
obtained via a logical acquisition because it provides access to file system data. While this is 
not a substitute for a physical acquisition, it is the next best thing. For most iOS devices, 
which are not jailbroken, a file system image is the most data that we can obtain from the 
device using conventional methods. 

This method of acquisition provides access to the user data partition only. The system 
partition of the device is only acquired via physical access. Should the device be jailbroken, 
additional data will be captured during the acquisition. Most tools offer one method to 
acquire the file system of an iOS device. Cellebrite offers between one and three methods, 
all of which differ per device. Method 1 and Method 2 are the most recognized by 
Cellebrite users. Some may even claim ignorance of the existence of Method 3, which is 
provided when a jailbroken device is connected. When so many options are presented, most 
examiners have a difficult time selecting the best option, especially when they are permitted 
a limited amount of time to capture the data. 

Wherever possible, it recommended that each method be captured to ensure that the most 
data is acquired for the device in support of the forensic acquisition. When this isn't 
possible, the fastest method suggested should be selected first followed by all other options 
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as time allows. Method 3 is the recommended acquisition approach for the jailbroken iOS 
devices and provides the most amount of data for the iPhone connected. Some compare 
Method 3 to a physical acquisition, but in reality, nothing but a true physical acquisition 
provides access to the amount of data that a physical acquisition does. 



oose an extraction method 


Connect> Prepare> Extract data 

The device ( iPhone with iOS 8.3 ) is jailbroken. 

The data extracted by each method will vary based on the device model and iOS version. 

Device: iPhone of H 



Extraction of a rich set of data including call logs, SMSs, MMSs, applications data, data files 
and notes. 

Extraction of a rich set of data including call logs, SMSs, MMSs, applications data, data files 
and notes. 

Extraction of the richest set of data including call logs, SMSs, MMSs, emails, applications 
data and locations. Recommended 


Back to start 


Advanced Logical Extraction options by UFED Physical Analyzer 

Currently, Cellebrite does not offer a method for merging the reports acquired by more than 
one file system dump method. Thus, the examiner is required to examine the output of each 
method separately and then compare and merge the results into a single report. 

The reality is that a file system dump, or Advanced Logical Extraction, as referred to by 
other forensic tools such as Cellebrite, enables the examiner to gain access to certain files 
and directories on the iOS device. Manual decoding and carving may be required, which 
will be covered in Chapter 6, iOS Data Analysis and Recovery. Some tools require the iOS 
device be in DFU mode prior to performing a file system image of the data. 
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Logical acquisition 

A logical acquisition captures what is accessible to the user. In simple terms, it often ignores 
the underlying and system files. Deleted data may be reported during a logical acquisition 
simply because the files are marked as deleted but they exist in the free space of the SQLite 
databases saved on that device. We will discuss recovering SQLite data and deleted artifacts 
in Chapter 6, iOS Data Analysis and Recovery. 

A logical acquisition is the simplest to ascertain if the device is unlocked, as it simply 
captures the active user data on the device. Most tools and methods that support logical 
acquisition of iOS devices will fail if the device is locked. Some think that if a physical 
image is captured, there is little to no need for a logical acquisition. However, not all data is 
parsed in a physical image, which is why having access to logical image, resulting in 
readable data will assist in digging deep in the physical image for artifacts to support your 
forensic investigation. 

A logical image is similar, if not the same data, as obtained during a backup copy of the iOS 
device. Backup image files will be discussed in Chapter 5, Data Acquisition from 
iOS Backups. Even though the data is captured in a similar manner during a logical and 
backup acquisition, it is important for the examiner to understand the differences the tools 
offer and to capture both, wherever possible. 

A logical acquisition is the fastest, easiest, and cheapest way to gain access to data stored on 
an iOS device. There are a variety of tools ranging from commercial to free that are capable 
of capturing logical acquisitions. Most of these tools require the device be unlocked or 
access to the plist file from the host machine be readily available. The lockdown file, which 
is stored as plist file on "trusted computers" enables the examiner to trick the device into 
believing it is unlocked or "trusted" on the forensic workstation. The lockdown files are 
located in /var/db/lockdown on OS X Macs and in C : \ProgramData\Apple\Lockdown 
on Windows 7 and later releases. Once these files are located, the examiner can leverage the 
files to access the device. In the following sections, we will cover bypassing locked iOS 
devices and brute-forcing password cracking, where possible, using different methods. 
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The following table summarizes the acquisition possibilities on non-jailbroken iOS devices: 


Model 
iPhone 3G 
iPhone 3GS 
iPhone 4 
iPhone 4S 
iPhone 5 
iPhone 5C 
iPhone 5S 
iPhone 6 
iPhone 6 Plus 
iPhone 6S 
iPhone 6S Plus 


Physical 

Yes 


No 


File System 

Yes 


Yes (if 

unlocked/ or 
passcode is 
cracked) 


iPad 
iPad 2 
iPad 3 
iPad 4 
iPad mini 
iPad Air 
iPad mini 2 
iPad Air 2 
iPad mini 3 
iPad mini 4 
iPad Pro 


Yes 


Yes 


No 


Yes (if 

unlocked/ or 
passcode is 
cracked 


Logical 

Yes 


Yes (if 
unlocked/ or 
passcode is 
cracked) 


Yes 


Yes (if 
unlocked/ or 
passcode is 
cracked 


iOS device support for non-jailbroken devices 
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Bypassing the passcode 

iOS devices provide an option for users to set a passcode on their device to prevent 
unauthorized access. Once a passcode is set, whenever the device is turned on or awakened 
from sleep mode, the passcode is required to access the data. Depending on the settings 
selected by the user, the iOS device may remain unlocked or automatically lock after a set 
amount of time. However, just because the device is in the unlocked state does not mean an 
examiner can connect it to a forensic workstation and forensically acquire the data without 
any issues. Some acquisition methods require the device to reboot, which will lock the 
device upon start-up. Additionally, some acquisition methods require the examiner to enter 
the passcode on the iOS device prior to the acquisition initiating. This is one of the hardest 
concepts to grasp as an examiner. Just when it seems like we have a stroke of luck, the tool 
requests the passcode to proceed. 

Before we go any further, let's discuss the current methods for locking iOS devices. iOS 
supports a simple four-digit code, a six-digit passcode, and complex alphanumeric 
passcodes of any length. Introduced with the iPhone 5S, the user fingerprint scan can also 
be used to lock/unlock the device. For iPhone 5S, the user must also select a simple four- 
digit code to use in case the fingerprint is not recognized. By default, the passcode is a four- 
digit numeric code, but by modifying the settings, it can be set to be a complex passcode. 
The user also has the option to erase all the contents on the iPhone after 10 failed passcode 
attempts. Even when a fingerprint is in place, most forensic tools require that the passcode 
that backs up the fingerprint be used to access the data on the iOS device. 

Passcode-locked devices are being utilized more frequently due to general user awareness 
of theft and security policies from organizations. Circumventing the passcode is not always 
possible due to security improvements in iOS. The forensic examiner should try to obtain 
the passcode from the owner to prevent issues in acquiring data from locked iOS devices. 
When the passcode is known, it can be entered in the forensic tool as shown in the 
following figure. Once the passcode is entered correctly, it is saved for the session and 
cached to the forensic workstation. You may find that other tools leverage the cached 
session password and can also acquire the locked iOS device. Guessing passwords within 
the forensic tool is the best method, as guessing on the iOS device itself can cause the user 
data to be wiped. 
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'est passcodes 


Connect > Prepare > Extract data 

Use this option if you don't know the passcode: 

Recover the passcode for me > 


If you know the passcode, enter it here to save time: 

oooo Q 

The passcode consists of four digits from 0 to 9. 

The passcode has been saved for this session. 


< Back 


Test passcode option in UFED Physical Analyzer 

In the initial releases of iOS until iOS 3, the passcode for unlocking the device was stored 
directly in the keychain, a place to store passwords securely on the iPhone. This passcode 
security can be bypassed by just removing the record from the keychain or by removing the 
UI setting that asks for the passcode after booting with the custom ramdisk. 

Since iOS 4, the passcode is not stored on the device in any format. By setting a device 
passcode, the user automatically enables data protection, which protects the data at rest. 
With data protection, the data on the device is encrypted with a set of class keys stored in 
the system keybag. The system keybag itself is protected by a passcode key, generated from 
the user's passcode and the device's UID. So, in order to decrypt the protected keychain 
items and files on the file system, you first need to decrypt the system keybag. If there is no 
passcode, the system keybag can be easily decrypted. If there is a simple four-digit 
passcode, you will have to guess it to decrypt the system keybag. As the passcode is tangled 
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with the device's UID key, brute force attempts must be performed on the device. Also, the 
same passcode on different devices generates different passcode keys as the UID is unique 
for every device. Passcode brute force attacks performed at the springboard level introduce 
delays, lock the device, and may lead to the wiping of data. However, these protection 
mechanisms are not applicable when you are performing a brute force attack on a kernel 
extension (AppleKeyStore) to decrypt the system keybag. It is worth mentioning that some 
tools will attempt to crack the passcode on an iOS device by accessing the host computer for 
which that iOS device was connected and synced. The tool accesses the pairing key through 
an escrow file to decrypt the locked device. For this to work, the examiner would need to 
have access to both the iOS device and the host computer to which the device is backed 
up. To do this, you need to perform the following steps: 

1. Connect the iOS device to the Mac. 

2. Download the script from https : // github . com/ innoying/iOS-DataProtec 
t ion /blob /mast er/python_scripts/demo_brute force . py. 

3. On Mac OS X, open a terminal and run the following command: 

$sudo python python_scripts/demo_bruteforce . py 

The brute force script uses the 19 9 9 port opened with tcprelay . py to communicate with 
the ramdisk tools on the device. The script brute forces the passcode, decrypts the System 
keybag, dumps the data protection keys, and places them into a directory named with 
the Unique Device Identifier (UDID) of the target device in a .plist format. 

O Note that this method may not work on newer iOS devices as the iOS-Data 
Protection tools were developed to support legacy iOS devices. 

As a result, you should see something like the following: 

Connecting to device : b716de79051ef093a98fc3f flc46ca5e36faabc3 Keybag UUID 

: 5bl4620bdle74013bfa66325b6946773 

Enter passcode or leave blank for bruteforce: 

Hit Enter on the keyboard to start the brute force process: 
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Trying all 4-digits passcodes 

O of lOOOO ETA: — : — : — 
lO of lOOOO ETA: 0:30:48 
20 of lOOOO ETA: 0:30:33 
30 of lOOOO ETA: 0:30:18 
40 of lOOOO ETA: 0:30:02 
50 of lOOOO ETA: 0:29:51 
1100 of lOOOO ETA: 0:25:54 
1110 of lOOOO ETA: 0:25:53 
lOOOO of lOOOO Time: 0:03:14 


100% \i 


0:03:14.543986 

{'passcode': '1111'. 'Ba&SidOSteKe y' : 

' If 5c25823297f 97f 3cb38d998726fc22787ca3f 31b8932c2b868700a341145b5 ' } 
True 


Kexbao system keybas (o) 

y^ r- vion ; 3 

Kjeybag 0 0 10 ; 5bl4620bdle74013bfa66325b6946773 


If the user chooses a strong passcode that is not easy to guess, we can still access the files 
protected with NSFileProtectionNone and keychain items protected by 
the kSecAttrAccessibleAlways data protection classes. 


Class 


Type 


Key 


Public key 


74 6f 01 65 8e c2 8 b 3 b a 9 9 339e 35 
6 5 cfb 69 5 2 6ea4 02622 7 cf5 f aaOdc 9066c 1092 


3 AES 

□1658ec28b3ba9’9339e35beb37232f89658fd0214eb4c4cac99976b05039 


3 Curve25519 

fc9066cl092e510aa586a2f62d9101e4 19600703 
a035e0f 5a6ee59b9e5928cc67b644c6a5cc8c5235cla5440a02686d222fc3a08 

3 AES 


a32826f0abaf6fblc049d395Daal2b07e05a310fb49626a5cef07 8ca4a7 a46f 4 
28 ec llf7 719 c 7b36d6f 4621aC 
bab62b621ebcfOTOc97ee9a2flfb6d: 
638ae8c4ala694b8ab2968eba28ef39al4( 

5071e2058e 14 8b7 d eee 5 b08 fd 


_ 3 AES 

r 462ia07c 3b088f e65c9909c7adb4 5cf 7 3ad8b9814a3 30 

3 AES 

3ee4al98f 5a49a7 e2 3 3c9dcdf 2805 292eO 

39al4d5397efl02e4872395df619bd00d31 
1 AES 

d685c0b29cd9d717f57732647dee0239513c7c79 

3 aes 

3702f4dd5b3b9i(j86db9fi7577d5f34bbf26e9a6f2d59 


f20594ea308d72919el82531 


3d8fbd6b41c520fldc8ebe6786abe4848ral799456300D89c630c2 3ff931d6c8 
'fSS040ha5 


On a Windows computer, tools such as the IP-Box, a Chinese hacker tool, can be used to 
brute force the passcode. Keep in mind that this method can wipe the device if the user 
elects to wipe the device after 10 failed passcode attempts, which is shown in the following 
screenshot: 
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••ooo Verizon 10:22 PM f $ 33* C3 

< Settings Touch ID & Passcode 


Voice Dial 

C 

Music Voice Control is always enabled. 


ALLOW ACCESS WHEN LOCKED: 

Today 

o 

Notifications View 

c 

Siri 

CD 

Reply with Message 

CD 

Wallet 

CD 

Get cards or passes ready from the lock screen by 
double-clicking the home button. 

Erase Data 

CD 


Erase all data on this iPhone after 10 failed passcode 
attempts. 

Data protection is enabled. 


User settings to wipe data after 10 failed passcode attempts 

The iP-Box was tested and evaluated by Detective Cindy Murphy. Her work is referenced 
in the following screenshots. 

© Detective Murphy's work on the IP-Box and instructions for use can be 

found at http: / / smarterf orensics . com/wp-content/uploads/201 
4 / 06/ IP-Box-documentation-rev2-l-l 6-2015. pdf. 

This "black box" essentially provides access to otherwise inaccessible iOS devices due to the 
lock state. Brute force and dictionary attacks are run against the devices to provide access 
for forensic acquisition. The following screenshot shows the iP-Box attempting to crack a 
locked iOS device: 
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Detective Murphy using the iP-Box to crack a locked iOS device 

The iP-Box requires special cables and iP-Box Software to gain access to the passcode of the 
device. False positives are common and require the examiner to restart the brute force 
attack. This method, while time consuming, can provide great success for otherwise 
inaccessible devices. The iP-Box claims support for all iOS versions and models. However, 
this tool was not designed for forensics and it is at the examiner's discretion to use it. For 
devices running iOS 8 and later versions, the cables shown in the following screenshot are 
required. According to Detective Murphy's white paper, these cables can be purchased from 
https : / / www . tone fun shop . co . uk/cable_picker/ 98 63 6_iPBox_iOS8_Adapter . htm 
1 . 



Cables required for use with iP-Box for devices running iOS8+ 

If you own UFED Physical Analyzer, you can attempt to brute force the passcode by 
manually guessing the passcode in the tool. This is time consuming, as Physical Analyzer 
does not present the option to run dictionary files or customized keyword lists in attempt to 
crack passcodes. 
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As you can see, as discussed in Chapter 2, Understanding the Internals ofiOS Devices, the 
examiner must know the iOS version running on the device prior to acquisition, certain 
brute force lock bypass attempts, and analysis. 

Other tools exist that offer a similar capability, such as UFED User Lock Code Recovery 
Tool. Just like the iP-Box, this tool requires specialized cables and a camera, which senses 
screen changes on the iOS device to crack the passcode. The UFED User Lock Code 
Recovery Tool can bypass locks on both iOS and Android devices as shown in the following 
screenshot: 


UFED User Lock Code Recovery Tool 

Disclaimer: All actions are subject to the full responsibility of the user, and 
Cellebrite is not liable for any damage to the device. 

Follow the instructions to recover the lock code. 

Before you begin, check your computer's power options to make sure it won't go 
into sleep mode. The process could take from a few minutes up to 21 hours. Vou 
can still use the computer during this time. 


liJhat type of device is it? 

[ 1 ] Android 

[2] iOS (Apple) 

[0] Exit 


UFED User Lock Code Recovery Tool 

For criminal investigations, Cellebrite Advanced Investigative Services (CAIS) can crack 
the passcode on an iOS device that is mailed to them by law enforcement agencies 
worldwide. They in turn send you the passcode and/or the unlocked device, enabling you 
to conduct your forensic acquisition and analysis. 

O More information on CAIS can be found on their website http : / / www . ce 

llebrite . com/Pages/ cellebrite-solution-for-locked-apple-d 
evices-running-ios-8x. 
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Acquisition of jailbroken devices 

We recommend treating all iOS devices the same. This means, do not try to handle 
jailbroken devices one manner and non-jailbroken in another manner. Essentially, try 
everything possible to gain access to that device. First, try a physical acquisition. If this 
method fails, attempt a file system acquisition, followed by a logical acquisition. If the 
device is locked and the passcode is required to acquire the device, attempt to crack it. The 
state of the iOS device should not keep you from trying your hardest to get a full physical 
image. For devices that are truly jailbroken, you will see how much easier this makes your 
life when attempting to acquire data. 

There are several methods on both Mac and Windows platforms that support the 
acquisition of iOS devices. Earlier, we discussed the physical and file system section of this 
chapter; UFED Physical Analyzer offers additional support for jailbroken iOS devices. If the 
device is jailbroken, a physical acquisition is possible. The exception to this is the 64-bit 
iPhone 6, 6 Plus, 6S, and 6S Plus. Currently, Elcomsoft is the only forensic tool offering 
support for physical acquisition of these newer devices. However, they must be jailbroken. 

Best practices recommend obtaining a forensic acquisition prior to connecting the iOS 
device to terminal on a Mac and attempting to access the data directly. In order to 
determine if the device has been jailbroken, the examiner has a few options: 

• Attach the iOS device to your forensic kit and perform an acquisition. If it's a 
newer iOS device and physical acquisition is supported, it's likely the device is 
jailbroken. Caution: The reported state of the device is not always correct! 

• Examine the fstab file to determine if the system partition is read only (ro) or 
read/write (rw). If the device is jailbroken, it can be accessed via a Mac using 
terminal to SSH into the device and mount the file system using iFuse or similar 
methods. Once the device is connected, we can navigate to private I etc I 
fstab. Examine the fstab to determine if /dev/ diskOslsl is ro or rw. If the 
partition is rw, the device is jailbroken and is likely running a version prior to iOS 
7. This file is no longer updated from ro to rw on newer iOS versions. We believe 
the file stopped being updated with a version of iOS 7. 

• Look for traces of jailbroken applications and startup screens as described 
in Chapter 2, Understanding the Internals ofiOS Devices. 
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Regardless of the method used to identify a jailbreak, it is recommended that the examiner 
use more than one way to identify the state of the iOS device. Why, you may ask? Take a 
look at the following screenshot: we can see the Device Summary provided by UFED 
Physical Analyzer after a file system acquisition: 


Owner Name 
Last Used ICCID 
Phone Number 
Serial number 

Backup Data 

Last Backup Computer Name 
iPhone of H 

Time Zone 
Activation State 


iPhone of H 


151 

Dll 


HEATHERMAHAUK 


America/New_York 

Activated 


WiFi Address 

Bluetooth Address 

Storaae Available (Bvtes^^ 

dO:. ■ 
dO:H 
8.040 GB 

LJlOf 

1 JO 

1 Jailbreak 



1 Is Jailbroken 

True 


Local network IP 

192. ljf ' 

1'W 

Wi-Fi MAC 

I 

1 L 


UFED Physical Analyzer identifying an iPhone6 as being jailbroken 


When examining the fstab of the same iPhone, we get the results shown in the following 
screenshot, which would lead the examiner to believe that this device is not jailbroken. 


Tdev^ I 
/dev/c^^^H^^T/TT^^aTe/va r hfs rw 0 2 

/dev/disk0sls3 /private/var/wireless/baseband_data hfs rw 0 2 


Examining fstab on a Mac 

When a discrepancy like this occurs, it is recommended that you first identify the iOS 
version running on the device as explained in Chapter 2, Understanding the Internals ofiOS 
Devices. Once identified, if the iOS version is iOS 7+, the fstab cannot be relied upon as a 
trusted source of a jailbreak state. Thus, the examiner needs to try more than one tool to see 
what options are offered during acquisition (for example, physical acquisition success of an 
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unsupported device, method 3 offered for file system acquisition, and so on.) 

There are several methods available on both Mac and Windows computers for acquiring 
data from jailbroken devices. Free Windows tools, such as Magnet CE, will create image 
files of jailbroken devices. When a jailbroken device is connected, the tool will provide file 
system, hence the examiner should realize they are dealing with a jailbroken iOS device. 

As shown in the following screenshot. Full is grayed out because the attached iOS device is 
not jailbroken. When the examiner selects More info this is explained. If this device were 
jailbroken, the option would be selectable and the acquisition would ensue. 



FULL -ALL FILES AND FOLDERS 

A full image Is a physical or file-system logical image Magnet ACQUIRE can extract a full image from 
iOS devices only when they are |ailbroken and running AFC2 


OS Methods 

Acquisition results 

5.x to 8 3* Apple File Conduit 2 
(AFC2) 

•Requires 

jailbroken 

device 

For jailbroken iOS devices, recovers a full 
logical file system dump that includes all of the 
files, folders, user data and native data 




OKAY 


Magnet CE acquisition options for a non-jailbroken device 

On a Mac, a user can SSH into the jailbroken iOS device and acquire/copy data from the 
device onto external media for examination. This is the fastest way to triage an iOS device, 
as the access is immediately granted. The following screenshot shows the iPhone mounted 
with access to applications stored on the device: 
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- 


Favorites 
(5) All My Files 
C2> iCIoud Drive 
^ AirDrop 
;A; Applications 
B Desktop 
[5 Documents 
O Downloads 
Devices 

O Remote Disc 

Tags 

# Red 

# Orange 

# Yellow 


Name 


logs 

Managed Preferences 
mobile 

Application Support 
Containers 
► Bundle 

▼ Data 

▼ Application 

► 0A1 6CD7E-2D41-41 37-9FC2-A553641 6B405 

► 0C756634-B524-4EB3-8B08-207AFF8460D9 

► 0CD9C300-839A-42E4-AF06-CD533875C87A 

► 0FE031 6F-4B1 0-4375-ADC6-F1 C97A3E01 4E 

► 1A8F8394-758A-4FOE-A4BE-7C847DB503EA 

► 2BF744BD-C4E7-48FD-A8A6-8D95D7E12EF3 

► 4ADA4729-1 D07-4EAF-9E72-A2242C8AE1 92 

► 4BB38EE7-CE6A-4693-BF69-50F8B79 00647 

► 5D3141A2-F198-454B-B1 D8-C0CC4BDF90D5 

► 9AF9BBED-FCE8-4C34-B01 8-A3D325BECD61 

a 9CfiAASfi4-nF4R-4nRn-RRFC-nCFAFfi1 FFC1R.5 


Date Modified 

Dec 21, 2015 
May 5, 2015, 
Sep 25, 2015 
May 5. 2015, 
Sep 25, 2015 
May 5, 2015. 
Sep 25, 2015 
Dec 23, 2015 
Dec 21, 2015 
May 5, 2015, 
May 5, 2015, 
May 5, 2015, 
May 5, 2015, 
Dec 21, 2015 
May 5, 2015, 
Aug 19, 2015 
Nov 10, 2015 
Nov 9, 2015, 
Dor 21 2015 


'< M- k ►' t> C 


Examining a jailbroken iPhone using ifuse to mount and view the data 

While this is the fastest way to triage a jailbroken device, it's not the best method for 
obtaining a forensically sound image, as the device is mounted and data can be changed or 
modified. Best practices recommend creating a forensic image prior to interacting directly 
with the iOS device when possible. 

For jailbroken iPhones, refer to the acquisition support in the following table. At the time of 
writing, it is still legal to jailbreak iPads, and they are not included in the preceding table as 
we are not encouraging illegal activity to gain access to user data on iOS devices. 
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JAILBROKEN 

Model 

Physical 

File System 

Logical 

iPhone 3G 

iPhone 3GS 

iPhone 4 

Yes 

Yes 

Yes 

iPhone 4S 

iPhone 5 

iPhone 5C 

iPhone 5S 

Yes (if 
unlocked/ or 
passcode is 
cracked) 

Yes (if 
unlocked/ or 
passcode is 
cracked) 

Yes (if 
unlocked/ or 
passcode is 
cracked) 

iPhone 6 

iPhone 6 Plus 

iPhone 6S 

iPhone 6S Plus 

Yes (if 64-bit is 
supported and if 
unlocked/ or 
passcode is 
cracked) 


iOS device support for jailbroken iPhones 


Summary 

The first step in the iOS device forensic examination is to acquire the data from the device. 
There are several different ways to acquire data from an iOS device. This chapter covered 
physical, file system, and logical acquisition techniques, including techniques of acquiring 
jailbroken devices and methods to bypass passcodes using commercial, free, and hacker 
tools. Physical acquisition is the preferred acquisition method as it recovers as close as we 
can get to a bit-by-bit copy of the data from the device; however, it is not possible to 
perform physical acquisition on all iOS devices. 

While physical acquisition is the best method for forensically obtaining a majority of the 
data from iOS devices, backup files may exist or be the only method to extract data from the 
device. 

The next chapter discusses iOS device backup files in detail to include user, forensic, 
encrypted, and iCloud backup files, and the methods to conduct your forensic examination. 
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Backups 


In the previous chapter, we covered techniques to acquire data from an iOS device. This 
chapter covers techniques to acquire a backup of files from the device onto a computer or 
iCloud using Apple's synchronization protocol. 

The physical acquisition of an iOS device provides the most data in an investigation, but 
you can also find a wealth of information on iOS backups. iOS device users have several 
options to back up data present on their devices. Users can choose to back up data to their 
computer using the Apple iTunes software or to the Apple cloud storage service known 
as iCloud. Every time an iPhone is synched with a computer or to iCloud, it creates a 
backup by copying the selected files from the device. The user can determine what is 
contained in the backup, so some may be more inclusive than others. Also, the user can 
back up to both a computer and iCloud, and the data derived from each location may differ. 
This often occurs due to the limitations of iCloud free storage. The user may simply back up 
photos and contacts to iCloud, but they take a complete backup of all data on 
their computer. As previously mentioned, a physical acquisition provides the best access to 
all data on the iOS device; however, depending on the device, the best information may be 
recovered from a backup file. 

In this chapter, we will cover the following topics: 

• iTunes and iCloud backup files 

• Creating and analyzing backup files 

• How to handle encrypted backup files 

• Backup file contents, file structure, and artifact recovery 
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iTunes backup 

A wealth of information is stored on any computer that has been previously synched with 
an iOS device. These computers, commonly referred to as host computers, can have 
historical data and passcode-bypass certificates. In a criminal investigation, a search 
warrant can be obtained to seize a computer that belongs to a suspect to access the backup 
and lockdown certificates. For all other cases, consent or permissible access is required. iOS 
backup file forensics mainly involves analyzing an offline backup produced by an iPhone, 
iPad, iPod touch, and/or Apple Watch. The Apple Watch data will be contained within the 
iPhone backup for which is it synched. 

The iTunes backup method is also useful in cases when physical, file system, and logical 
acquisition of an iOS device is not feasible. In this situation, examiners essentially create an 
iTunes backup of the device and analyze it using forensic software. Thus, it is important for 
an examiner to completely understand the backup process and the tools involved to ensure 
they are capable of creating a forensic backup without contaminating the devices with other 
data existing in iTunes. 

iPhone backup files can be created using the iTunes software, which is available for the 
MAC OS X and Windows platforms. iTunes is a free utility provided by Apple for data 
synchronization and management between iOS devices and the computer. iTunes uses 
Apple's proprietary synchronization protocol to copy data from the iOS device to a 
computer. For example, an iPhone can be synched with a computer using a cable or Wi-Fi. 
iTunes provides an option for encrypted backup, but by default, it creates an unencrypted 
backup whenever an iPhone is synched. Encrypted backups, when cracked, provide 
additional access to data stored on the iOS device. This will be discussed later in this 
chapter. 

Users often create backup files to protect their data in the event that there device is 
damaged or lost. We either create a forensic backup to act as the best evidence or simply 
extract data from existing iOS backup files to search for legacy information. For example, if I 
am under investigation and I delete files or wipe my iPhone, my backup files on iCloud and 
my Mac still exist. Depending on whether iTunes or iCloud was used, multiple backups for 
the same device may exist. The examiner will have to forensically analyze each backup to 
uncover artifacts relating to the investigation. 

iTunes is configured to automatically initiate the synchronization process once the iOS 
device is connected to the computer. To avoid unintended data exchange between the iOS 
device and the computer, disable the automatic synchronization process before connecting 
your evidence to the forensic workstation. The screenshot in step 2 illustrates the option 
that disables automatic syncing in iTunes Version 12.3.1.23. 
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To disable auto-syncing in iTunes, perform the following steps: 

1. Navigate to iTunes I Preferences I Devices. 

2. Check Prevent iPods, iPhones, and iPads from syncing automatically and click 
on the OK button. 


Devices Preferences 


► VSi ■ ® ■ 

General Playback Sharing Store Parental Devices Advanced 

Device backups: 


Heather Mahalik's iPad 

1/25/16, 4:45 PM 

Heather Mahalik's iPhone 

11/11/15, 3:15 PM 

Heather Mahalik's iPhone 

4/3/15, 12:14 PM 

Heather Mahalik's iPhone 

10/27/14, 11:16 PM 

Heather Mahalik's iPhone - Oct 27, 2014, 8:09 PM 

10/27/14, 10:52 PM 

Heather Mahalik's iPhone - Oct 1, 2014, 3:59 PM 

10/1/14, 9:09 AM 

Heather Mahalik's iPhone - Oct 1, 2014, 6:12 PM 

10/1/14, 9:09 AM 


Q Prevent iPods, iPhones, and iPads from syncing automatically 
iTunes is not paired with any Remotes 

Cancel 


iTunes-disabling automatic sync 

3. As seen in the preceding screenshot, iOS backup files exist on the system. If this 
were a forensic workstation, these backup files would not exist or would be 
permanently removed to prevent cross-contamination. 

4. Once you verify the synchronization settings, connect the iOS device to the 
computer using a USB cable. If the connected device is not protected with a 
passcode, iTunes immediately recognizes the device. This can be verified by the 
iPhone icon displayed in the upper-left corner of the iTunes interface as shown in 
the following screenshot: 
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« 

<s>~ 0*2 ! 

Heather Mahalik's iPhone 


iPhone 6s 

Capacity: 11.79 GB 


iOS 9.3 

Phone Number: ( 

■ 

Your iPhone software is up to date. iTunes wil 

Serial Number: 1^ 


check for an update again on 2/1/16. 

Check for Update Restore iPhone... 



11=1 Summary 

A Apps 
J1 Music 
p| Movies 
TV Shows 
® Podcasts 
KgS Photos 
(T) Info 

f] Music 
PJ Movies 
O TV Shows 
@) Podcasts 
IP Books 
CP Audiobooks 


Backups 

Automatically Back Up 

O iCIoud 

Back up the most important data on your iPhone to 
iCIoud. 

This computer 

A full backup of your iPhone will be stored on this 
computer. 

Encrypt iPhone backup 

This will allow account passwords, Health, and HomeKit data to 
be backed up. 

Documents & Data Other 


Manually Back Up and Restore 

Manually back up your iPhone to this computi 
backup stored on this computer. 


Back Up Now 


Restore Backup- 


Latest Backup: 

1/23/16, 6:27 AM to iCIoud 


1.55 GB Free 


Sync 


iTunes-iPhone recognized 

5. If the connected iPhone is protected with a passcode, iTunes prompts the user to 
unlock the device before starting the sync process, as shown in the following 
screenshot. Once the iPhone is unlocked with a valid passcode, iTunes recognizes 
the device and allows the user to back up and sync with the computer. Once an 
iPhone is successfully synched with a computer, iTunes allows it to back up 
without unlocking the device when the same iPhone is connected to that 
computer again. 
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iTunes could not connect to the iPhone “Heather Mahalik’s 
iPhone” because it is locked with a passcode. You must 
enter your passcode on the iPhone before it can be used 
with iTunes. 


More Information 


Cancel 


Try Again 


iTunes-iPhone locked message 

6. Once the passcode is entered, the user may enable Trust between the computer 
and the iPhone. The user will be prompted to press Continue on the computer 
and select Trust on the iPhone. 



Do you want to allow this computer to access information 
on “Heather Mahalik’s iPhone”? 

If you don’t allow access, you will not be able to manage or sync your 
iPhone with this computer. 


Cancel 


Continue 


iTunes-Access permissions 


[ 121 ] 










Data Acquisition from iOS Backups 


7. Once iTunes recognizes the device, a single click on the iPhone icon displays the 
iPhone summary including the iPhone's name, capacity, firmware version, serial 
number, free space, and phone number, as shown in the preceding screenshot. 
The iPhone Summary page also displays the options to create backups. Steps to 
create a backup were discussed earlier in this chapter. 


Pairing records 

When iTunes detects the iOS device, sets of pairing records are exchanged between the 
device and the computer. Pairing is the mechanism by which your computer establishes a 
trusted relationship with your device so that iTunes can communicate with it. Once a 
computer has been paired, it can access personal information on the device and can even 
initiate a backup of the device. Pairing was introduced in iOS7 and is required for 
connecting with the device. At the time of writing this book, pairing is still in use. 

On the iPhone, pairing records are stored in the 

/ var/ root/Library/Lockdown/pair_records/ directory. Depending on your 
acquisition method, this directory may not be available for examination. The directory will 
contain multiple pairing records if the device is paired with multiple computers. Pairing 
records are stored as a property list ( . plist) file with a filename representing the unique 
identifier given to the computer. Property list files are binary-formatted XML-like files, 
explained in detail in Chapter 6, iOS Data Analysis and Recovery. Pairing records on the 
device contain the HostID, root certificate, device certificate, and host certificate. For 
example, the content shown in the following screenshot was located in a pairing record on 
one particular iPhone with a file 

named 97D62 99A-8EDA-454F-9C62-4BB031F45DD6 .plist. Pairing records stored on the 
iPhone are deleted only when the phone is restored to the factory state. 


« , 


u 97D6299A-8EDA-454F-9C62-4BB031F45DD6. plist 

[j 97D6299A 

8EDA-454F-9C62-4BB031F45DD6.plist No Selection 

Key 

Type 

Value 

▼ Root 

Dictionary 

(5 items) 

SystemBUID 

String 

519DF016-0F61-44E3-97BF-6S424A4ADA75 

HostID 

String 

97D6299A-8EDA-454F-9C62-4BB031F45DD6 

RootCertificate 

Data 

<2d2d2d2d 2d424547 494e2043 45525449 46494341 544S2d2d 2d2d2d0a 4d494943 72544343 415a5767 41774942 41674942 4144414e 42676b71 686b6947 3 

DeviceCertificate 

Data 

<2d2d2d2d 2d424547 494e2043 45525449 46494341 54452d2d 2d2d2d0a 4d494943 4e6a4343 41523667 41774942 41674942 4144414e 42676b71 686b6947 3 

HostCertificate 

Data 

<2d2d2d2d 2d424547 494e2043 45525449 46494341 S44S2d2d 2d2d2d0a 4d494943 756a4343 41614b67 41774942 41674942 41444 14e 42676b71 686b6947 3 



Pairing records on the iPhone 

On the computer, pairing records are stored in a preconfigured location depending on the 
operating system as shown in the following table. Pairing records are stored as a property 
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list file with a filename representing the iPhone's unique device identifier. Pairing records 
on the computer are known as lockdown certificates. 


Operating system 

Location 

Windows 

%AllUserProf i le%\ Apple \ Lockdown \ 

Mac OS X 

/private/var/ db/ lockdown/ 


Pairing records on the computer contain the device certificate. Escrow keybag, root 
certificate, host certificate, host private key, and root certificate and private key. For 
example, the content shown in the following screenshot was located in a pairing record on 
one particular computer with a file named 

6clb7aca59e2eba6f 4 635cf e7c4b2delbd8 12 8 98 . plist. 



Pairing record on a computer 

The Escrow keybag stored on the computer allows iTunes to back up and sync with the 
device even in a locked state. The Escrow keybag is a copy of the System keybag and 
contains a collection of data protection class keys that are used for encryption on the iOS 
device. Commercial tools that claim to be able to crack a locked iPhone without brute force 
require access to the host computer and thus the Escrow keybag. The keybag improves the 
user experience during device synchronization and gives access to all classes of data on the 
device without entering the passcode. 

The Escrow keybag is protected with a newly generated key computed from the key 0x835 
and stored in an escrow record on the device. The escrow record is a property list file stored 
in the /private/var/ root/Library/Lockdown/escrow_records/ directory with a 
filename that represents the computer's unique identifier. Starting with iOS 5, escrow 
records are protected with the UntilFirstUserAuthentication data protection class, 
which ties the encryption to the user's passcode. So, the device passcode must be entered 
before backing up with iTunes for the first time and, starting with iOS7, the device and 
computer must form a Trust. 
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Understanding the backup structure 

When the iPhone is backed up to a computer, the backup files are stored in a backup 
directory, which exists as a 40-character hexadecimal string and corresponds to the Unique 
Device Identifier (UDID) of the device. The backup process may take a considerable 
amount of time depending on the size of the data stored on the iPhone during the first 
backup. The location of the backup directory in which your backup data is stored depends 
on the computer's operating system. The following table displays a list of the common 
operating systems and the default location of the iTunes backup directory: 


Operating system 

Backup directory location 

Windows XP 

\Documents and Settings\ [user name] \Application 

Data\ Apple Comput er\Mobile Sync \ Backup \ 

Windows 

Vista/7/8+/10 

\Users\ [user name] \AppData\Roaming\Apple 

Comput er\MobileSync\Backup\ 

Mac OS X 

-/Library /Application Support /Mobile Sync /Backup/ 

(~ represents your Home folder) 


iOS backup file locations 

During the first sync, iTunes creates a backup directory and takes a complete backup of the 
device. Currently, on subsequent syncs, iTunes only backs up the files that are modified on 
the device and updates the existing backup directory. This has not always been true as in 
the past a new backup was created every time the iOS device was backed up. Also, when a 
device is updated or restored, iTunes automatically initiates a backup and takes a 
differential backup. A differential backup has the same name as the backup directory, but 
is appended with a dash (-), the ISO date of the backup, a dash (-), and the time in a 24- 
hour format with seconds ( [UDID] + + [Date] + + [Time stamp]). 

In the following screenshot, we see both normal and differential backup files: 


— 

■H Backup ► 

44d5fa67acc1d9235bc1cb8bda69fb22b93c3ada 

44d5fa67acc1d9235bc1cb8bda69fb22b93c3ada-201 41 027-20091 3 

611 e51 eaac46cc299d234f4ec325fad36ad1 3fc2 4 

a6abc99a42b873f202 1 31 93641 1 86d5f62498b80 f 

a6abc99a42b8 7312021 3193641 1 86d5f62498b80-201 41 001-1 55931 

a6abc99a42b873f2021 31 93641 1 86d5f62498b80-201 41 001 - 1 81 240 

a8634e49a99eb8d9368344d70f5563df662f5d3a 

d3de27af4d79490359f06dd1 9fe249964f451 270 



User created and differential backup files on a Mac 
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The iTunes backup may make a copy of everything on the device to include contacts, SMS, 
photos, the calendar, music, call logs, configuration files, documents, the keychain, network 
settings, offline web application cache, bookmarks, cookies, application data (if selected), 
and so on. For example, e-mail and passwords will not be extracted if the backup is not 
encrypted. The backup also contains device details such as the serial number, UDID, SIM 
details, and phone number. This information can also be used to prove a relationship 
between the backup and the mobile device. 

The backup directory contains four standard files along with the individual data files, 
which may exist in various formats depending on the version of iTunes. Older versions will 
contain * . mdbackup, * .mdata, * .mdinfo, and some files with no file extensions, which 
have been used by the most recent versions of iTunes. The standard files store details about 
the backup and the device from which it was derived. It's worth noting that these files 
should remain unencrypted regardless of the state of the backup. These file names are as 
follows: 


• info.plist 

• manifest . plist 

• status .plist 

• manifest . mbdb 

The first three files are property list files that can be easily analyzed using the Property List 
Editor application on Mac OS X or Windows. 

info.plist 

The info.plist file stores details about the backed up device and typically contains the 
following information: 

• Device name and display name: This is the name of the device, which typically 
includes the owner's name 

• ICCID: This is the Integrated Circuit Card Identifier, which is the serial number 
of the SIM 

• Last backup date: This is the timestamp of the last successful backup 

• IMEI: This is the International Mobile Equipment Identity, which is used to 
uniquely identify the mobile phone 

• Phone Number: This is the phone number of the device at the time of backup 

• Installed applications: This is the list of application identifiers on the device 

• Product type and production version: This is the device's model and firmware 
version 
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• Serial number: This is the serial number of the device 

• iTunes version: This is the version of iTunes that generated the backup 

• Target Identifier and Unique Identifier: This is the UDID of the device 


manifest.plist 

The manifest . plist file describes the contents of the backup and typically contains the 
following information: 

• Applications: This is a list of third-party applications installed on the backed up 
device, their version numbers, and bundle identifiers. 

• Date: This is the timestamp of a backup created or last updated. 

• IsEncrypted: This identifies whether the backup is encrypted or not. For 
encrypted backups the value is True, otherwise it is False. 

• Lockdown: This contains device details, the last backup computer's name, and 
other remote syncing profiles. 

• WasPasscodeSet: This identifies whether a passcode was set on the device when 
it was last synched. 

• Backup keybag: Starting with iOS 4, a Backup keybag is created for each backup 
made by iTunes. The Backup keybag contains a new set of data protection class 
keys that are different from the keys in the System keybag, and backed up data is 
re-encrypted with the new class keys. Keys in the Backup keybag facilitate the 
storage of backups in a secure manner. 


status.plist 

The status .plist file stores details about the backup status and typically contains the 
following information: 

• BackupState: This identifies whether the backup is a new backup or one that has 
been updated 

• Date: This is the timestamp of the last time the backup was modified 

• IsFullBackup: This identifies whether or not the backup was a full backup of the 
device 
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manifest.mbdb 

The manifest . mbdb file is a binary file and contains records about all other files in the 
backup directory along with the file sizes, file type, and file structure. 

O Hal Pomeranz, a SANS instructor, wrote a script to parse the 

manifest .mbdb file for forensic analysis: https : //github . com/halpom 
eranz/mbdbls. Hal's parser will work even on encrypted backup files. 

The manifest . mbdb file header and record format are shown in the following tables. 


Header 

The file header is a fixed value of 6 bytes. This value acts as a magic string to identify the 
file format. 


Type 

Data 

Description 

uint8 

mbdb\5\0 

This files a magic string 


Themanifest . mb db file header 


Record 

Each record in the manifest .mbdb file contains details about a file in the backup. 


Type 

Data 

Description 

String 

Domain 

This is the domain name 

String 

Path 

This is the file path 

String 

Target 

This is an absolute path for symbolic links 

String 

Digest 

This contains SHA1 hash OxFF OxFF for directories and for 
AppDomain files, and 0x00 0x14 for SystemDomain files 

String 

Encryption key 

This indicates encrypted files and OxFF OxFF 
for unencrypted files 

uintl6 

Mode 

This identifies file type OxAOOO for symbolic link, 0x4000 for 
directory, and 0x8000 for regular files 

uint64 

inode number 

This is a lookup entry in the inode table 
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Type 

Data 

Description 

uint32 

User ID 

This is mostly 5 01 

uint32 

Group ID 

This is mostly 5 01 

uint32 

Last modified time 

This is the file's last modified time in the Unix time format 

uint32 

Last accessed time 

This is the file's last accessed time in the Unix time format 

uint32 

Created time 

This is the file created time in the Unix time format 

uint64 

Size 

This is the length of a file. It is for a symbolic link and a 
directory 

uint8 

Protection class 

This is the data protection class 0x1 To OxB 

uint8 

Number of properties 

This is the number of extended attributes 


The manifest . mbdb file record 


Apart from the standard files, the backup directory also contains hundreds of backup files 
with varying file extensions depending on the version of iTunes used to create the backup, 
as described earlier. In the following screenshot, we can see that the backup was created 
with the latest version of iTunes in which the files do not contain a file extension. The 
backup files are uniquely named with a 40-character hexadecimal string. These filenames 
signify a unique identifier for each data set copied from the iPhone. 


Name 

* Date Modified 

Size 

Kind 

ff228ea8762c50bc4c4885ae386f85be6b2a936a 

Today, 3:27 PM 

42 KB 

TextEd...ument 

ff 229ca0b40955b464c6e9cb5385 1 4a 7de89 7 1 a8 

Today. 3:29 PM 

288 bytes 

TextEd...ument 

ff543aff217faa3c4dbd073a1a1 9374031 e0d20b 

Today. 3:28 PM 

1.2 MB 

TextEd.-.ument 

tf21 421 0ff41 1 7afce6dfb551 84d01 771 aeca290 

Today. 3:29 PM 

1 6 bytes 

TextEd...ument 

ffa2f 70e0794cca929e5800074fde1 6 1 8ea2bff8 

Today. 3:28 PM 

63 KB 

TextEd.-.ument 

ffal 6218d71b0bffe6673b64de8946575fb00fe5 

Today. 3:28 PM 

2.4 MB 

TextEd.-.ument 

ffafd25c802885304da446f694b9455b4b1ecf59 

Today, 3:28 PM 

27 KB 

TextEd.-.ument 

ffbl 2157 189751 9be542d3bd2e4 1 e67bd59e955c 

Today. 3:28 PM 

752 bytes 

TextEd.-.ument 

ffb44e77b571 2f514167de4361fb572088b9445f 

Today. 3:29 PM 

832 bytes 

TextEd.-.ument 

ffb8647db025c77e7191c649d4192085d2f4f763 

Today. 3:29 PM 

1 6 bytes 

TextEd.-.ument 

Mb43027a5f8c9bb4df95fadc34a860296e380f1 

Today, 3:28 PM 

657 KB 

TextEd.-.ument 

ffbfce86 1 9f9e870ca2b5ad803cafa2c 1 d62fa98 

Today. 3:28 PM 

28 KB 

TextEd,..ument 

ffe3d25 1 b6b524755 1 c6c635a72f825c1 b42ae94 

Today, 3:27 PM 

1 6 bytes 

TextEd.-.ument 

ffe6f346afd1002739b01876e6b67c2acb07d0a6 

Today. 3:27 PM 

16 bytes 

TextEd.-.ument 

fffa29f01 6699c7897aa1 36fc946557229b87ba5 

Today. 3:28 PM 

78 KB 

TextEd.-.ument 

Cl Info.pllst 

Today. 3:29 PM 

1.5 MB 

Proper.Jst File 

Manifest. mbdb 

Today. 3:29 PM 

2.2 MB 

Document 

/ Manifest. plist 

Today, 3:29 PM 

30 KB 

Proper...lst File 

*’ Status. plist 





iPhone backup files 
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In iOS, files are categorized into more than 12 domains. All of the application files are 
classified into the AppDomain class and other files on the file system are classified into 11+ 
system domains shown in the following screenshot. The list of system domains is stored in 
a property list file located under /System/Library/Backup/Domains .plist on the 
device. This file can be accessed via multiple acquisition methods and can be examined with 
free or commercial tools. 

The 40-character hexadecimal filename in the backup directory is the SHA1 hash value of 
the file path appended to the respective domain name with a dash (-) symbol. For instance, 
the AddressBook database file is a member of HomeDomain and is located 

under Library /AddressBook/AddressBook . sqlitedb. The backup file name 
of AddressBook is 31bb7ba8914766d4ba40d6dfb6113c8b614be442, which can be 
obtained by computing the SHA1 hash value of the string HomeDomain- 
Libr ary /AddressBook /AddressBook . sqlitedb. 


jt C:\Users\hmahalik\Desktop\Domains.plist 
File Edit View Help 


a&u 

JUflE 

Sr # 



XML View 

List View 


Key 



Type 

Value 

B Root 



diet 




MaxSupportedVersion 

string 

25.0 



MinSupportedVersion 

string 

3.0 


e System Domains 

diet 




-•©•• BooksDomain 

diet 




© CameraRollDomain 

diet 




© DatabaseDomain 

diet 




© HealthDomain 

diet 




ffl HomeDomain 

diet 




© KeyboardDomain 

diet 




ffl KeychainDomain 

diet 




© ManagedPreferencesCdict 




ffl MediaDomain 

diet 




© MobileDeviceDomaindict 




© RootDomain 


diet 




■ffl SystemPreferencesDo diet 




© TonesDomain 

diet 




ffl WirelessDomain 

diet 




Version 


string 

23.0 

plist Editor Pro V 2.1 


System domains on the iPhone 
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Unencrypted backup 

There are several tools available to create backup files. Some commercial tools, such as 
MSAB XRY and Cellebrite, will use iTunes to create a backup file for examination. If you 
don't have one of these tools, you can use a fresh installation of iTunes to create a backup 
file for examination. Keep in mind, an encrypted backup file that can be cracked provides 
us with access to more data than an unencrypted backup file. 

To create an unencrypted backup, perform the following steps: 

1. Connect the iOS device to the forensic workstation using the appropriate iPhone 
cable. 

2. On the forensic workstation, launch iTunes. 

3. Click on the iPhone icon displayed in the upper-left corner of the iTunes 
interface. It displays the iPhone Summary page. 

4. On the iPhone summary page, select the This computer checkbox and click on 
the Back Up Now button. Notice that the option to encrypt the backup is also 
located here. This will be covered later in this chapter. 







W 

fl B p ••• 

□ 

Heather Mahalik's iPhone 

SF9 Heather Mahalik's iPhone ± 

B9 h6GB | 60% SO* 

Capacity: 11.79 6B 

Phone Number: (■ 

Serial Number: ■ ■TS 

Settings 



fl=] Summary 


A- Apps 



/ ] Music 

HI Movies 


Backups 

□ TV Shows 
® Podcasts 


Automatically Back Up 

BiS Photos 


iCIoud 

Back up the most important data on your iPhone to 


Music 
H Movies 
□ TV Shows 
Podcasts 
II Books 


iCIoud. 


(tb pTh 


iOS 9.3 

Your iPhone software is up to date. iTunes wil 
check for an update again on 2/1/16. 


Check for Update 


Restore iPhone... 


Mam 

^Manu 


Manually Back Up and Restore 

Manually back up your iPhone to this comput 
;up stored on this computer. 


O This computer 

A full backup of your iPhone will be stored on this 
computer. 

Encrypt iPhone backup 

This will allow account passwords, Hoalth, and HomoKit data to 
be backed up. 

Change Password... 


Back Up Now 


Restore Backup.. 


.atest Backup: 

/our iPhone has never been backed up to thi 


iTunes-iPhone summary 
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5. Once the Back Up Now option is selected, iTunes will ask the examiner if they 
are sure that they do not want to encrypt the backup file. 



Do you want backups of "Heather Mahalik's iPhone" to be 
encrypted? 

If you proceed without encryption, the backups will not include 
sensitive data. Restoring a device from a backup will result in loss of 
your saved passwords, Health, and HomeKit data. 


Don't Encrypt 


Encrypt Backups 


iTunes prompt to choose whether to encrypt the backup or not 

6. For this example, we are electing to select Don’t Encrypt to demonstrate all 
options for creating iOS backup files. 


Extracting unencrypted backups 

There are many free and commercial tools available to analyze data from unencrypted 
backups. These tools parse the manifest .mbdb file, restore the filenames, and create the 
file structure that users see on the iOS device. Some popular tools include the iPhone 
Backup Extractor, iExplorer, and commercial tools such as BlackLight, XRY, Physical 
Analyzer, IEF Mobile, and more. 


iPhone Backup Extractor 

iPhone Backup Extractor is a free tool for Mac OS X, which can be downloaded from http : 
/ / www . iphonebackupextractor . com/ f ree-download/. This tool provides a great 
triage view for free, but it will have to be purchased to extract the full dataset contained in 
the backup. 

The Backup Extractor expects backup files to be located in the default location 

~/Library/Application Support/MobileSync/Backup/. The tool will allow you to 
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add additional locations should your backups be stored on external evidence drives. 

To extract the backup, follow these steps: 

1. Launch the app and click on the Add Backups (+) button if the tool doesn't 

automatically add the backup file from the default location. The tool will display 
a list of backups available on the forensic workstation. Both local and 
iCloudbackups can be selected for extraction. Select the backup that you wish to 
extract and click on the Choose button, as shown in the following screenshot: 


__ Heather Mahalik's iPhone 
Heather Mahalik's iPad 
__ Heather Mahalik's iPhone 
D Hea ^ ^ 
lea 

□ 


Backup details 

Device: iPhone 5 

Serial: C39JH1N 

Firmware: 8.1 


Preferences 



1 General iCIoud 


We always look for backups in your default folder. 

If you store backups in other folders, you can add them below: 



+ 



Use of this application is subject to our term: 


iPhone Backup Extractor-choosing backups 
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2. When you choose the backup, iPhone Backup Extractor allows you to extract the 
individual applications and the iOS file system backup, as shown in the following 
screenshot (more data is retrievable when the tool is purchased): 


• • • 

DEVICES 

▼ j_ Heather Mahallk's iPhone 

® 1/27/2016 3:29:27 PM 

▼ [] Heather Mahallk's iPad 

@ 1/25/2016 4:45:12 PM 

▼ Heather Mahalik's iPhone 
@ 11/11/2015 3:15:00 PM 
@ 10/1/2014 1:09:13 PM 
® 10/1/2014 1:09:13 PM 

▼ Heather Mahalik's iPhone 


iPhone Backup Extractor [UNREGISTERED] 


I 


Backup details 

Device: iPhone 5S 

Serial: DNPLV20SFNJK 

Firmware: 8.3 


Purchase tt Activate ^ Rate us 

Time: 8:09 PM 

IMEI: 358751057098192 

Status: Complete and unencrypted 


Folder: 61 1e51eaac46cc299d234f4ec325fad36ad13fc2 


Overview 


Preview Expert Mode App View 


® 5/5/201 5 8:09:04 PM 

Available data 




' 4/3/2015 12:14:02 PM 





▼ Q Heather Mahalik's iPhone 

41 Photos: 

Extract 1,574 

F». . 

Videos: 

Extract 69 

® 10/27/2014 11:16:38 PM 

Contacts: 

Extract 607 

jj£ Voicemail: 

Extract 161 

® 10/27/2014 10:52:36 PM 





Calendar: 

Extract 472 

Notes: 

Extract 20 


Qj SMS: 

Extract 5,789 

Call history: 

Extract 3,966 


4- Recordings: 

None 

Location data: 

Extract 76 


(§^, WhatsApp: 

None 




iPhone Backup Extractor 

3. Choose the files you would like to extract and then click on Extract. You are 
prompted for a destination directory to save the extracted files. 


iExplorer 

iExplorer is a free tool for Mac OS X and Windows, which can be downloaded from http : / 
/download. cnet . com/iExplorer/3000-2141_4-10969335 . html. This tool provides 
access to artifacts contained within an iOS backup file. Note, the Windows version requires 
an iOS device be attached for examination. iExplorer on Mac allows the examiner to connect 
an iOS device for examination or to examine backups contained in the default 
location ~/Library/Application Support/MobileSync/Backup/. You will need to 
copy any backups you wish to extract to the default location. Once downloaded and 
installed, this tool is very easy to use. 
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To extract the backup, follow these steps: 

1. Launch the app and select Browse iTunes Backups. 



Explorer 

2. The tool will show all backup files residing in the Backup directory. Select the 
iOS device you wish to examine. The available artifacts will be displayed. 
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i Explorer - forensic artifacts 


BlackLight 

BlackLight is a commercial tool offered by BlackBag Forensics. This tool is one of the few 
that function on both Windows and Mac OS X, proving great support for all iOS acquisition 
types, even for encrypted backup files where the passcode is known or the lockdown file is 
available. BlackBag also provide free training in the use of the tool; visit https : / /www . bla 
ckbagtech . com/ software-products/blacklight-6/blacklight . html for more 
information. 
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To extract the backup, perform the following steps: 

1. Launch the app and select Add and then Add iOS Backup... 



BlackLight - adding an iOS backup file 

2. Navigate to the backup file and then select the method for extraction. 

The Comprehensive option takes the longest, but parses the most artifacts for 
examination. 
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Evidence Selection: 

Partition Type 

* 611e51eaa... Directory Disk 

iOSBackup 


Name Evidence ID 

61 le5 Ieaac46cc299d234f4ec325fad36ad 13 ... 


1 


ocessing Options 


Presets: 

✓ Triage (Faster - Little Processing) 

Intermediate (Slower - More Processing) 


Q Signature An 

Comprehensive (Slow - Full Processing) 



Saved Settings (Template) 





CLIATTC 


Identify Known Files Settings... 


Unallocated Space: Locate Files 


Settings... 


These processing options can be run later from the Device Status screen. 


Cancel 


Add 


A- 


BlackLight - extraction options 
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3. When processing has completed, an Artifacts summary can be viewed. 


Cue info Timeline Search 


Heather Mahabk's iPhone 


■ BlackLight Case.BlackUght 

<£, S A ft 9 - !i I & £ * a « 

Detail* Browser File Filter Media Messaging Social Internet Email Contacts Phone Applications Calendar Locations Notes System 

Summary L Artifacts j History 


u Export Status 
■ Device Status 


C9 



Disk images 0 


1 10 100 1000 10000 




1 10 100 1000 10000 IOOOi 


BlackLight - Artifacts summary 

The best part of this tool is the access provided to the native files for deep dive analysis, 
which will be covered in Chapter 6, iOS Data Analysis and Recovery. 
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• • • 


9 BlackLight Case.BlackLight 

■ k! 

Phone Applications 

82 (~ \ 

Details Browser File Filter 

f W 

Media Messaging Social 

m S= 

Case Info Timeline Search 

Internet Email Contacts 

▼ DEVICES 

W-TTP 4 ¥ Root 




[] Heather Mahalik's iPhone Name 

Date Created 

Date Modified 

Date Accessed 

▼ ACTIVITY 

▼ mobile 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

^ Export Status 

► CD Applications 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


▼ C l Library 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

U Device Status 

► P i Accounts 

2016-01-28 (UTC) 

2016-01-28 (UTO 

2016-01-28 (UTC) 

▼ CONTENT SEARCHES 

► C~, AddressBook 

2016-01-28 (UTC) 

2016-01-28 (UTO 

2016-01-28 (UTC) 

▼ TACS 

WTT\ ► CiiBackBoard 

2016-01-28 (UTO 

2016-01-28 (UTO 

2016-01-28 (UTC) 


► 1 , BulletmBoard 

2016-01-28 (UTC) 

2016-01-28 (UTO 

2016-01-28 (UTC) 


► ^Caches 

2016-01-28 (UTO 

2016-01-28 (UTO 

2016-01-28 (UTC) 


► Q Calendar 

2016-01-28 (UTC) 

2016-01-28 (UTQ 

2016-01-28 (UTC) 


► CL CallHistory 

2016-01-28 (UTC) 

2016-01-28 (UTO 

2016-01-28 (UTC) 


► QCallHiitoryDB 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► com. apple. itunesstored 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► CO ConfiqurationProfiles 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► Cookies 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► CiiDataAccess 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► Cll Databases 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► ftjDeviceRegistry 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► lOeviceReqisttv. state 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► Ld.Mjil 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► C«. MobileBluetooth 

2016-01-28 (UTO 

2016-01-28 (UTO 

2016-01-28 (UTC) 


► LJ Notes 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► £] Passes 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 


► ^Preferences 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

» 

► Q Safari 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

2016-01-28 (UTC) 

Field Value 




^ 


BlackLight - broswer 


Decrypting the keychain 

For unencrypted backups, all the backup files are stored unencrypted except the keychain. 
The keychain file contents are encrypted with a set of class keys in the Backup keybag. The 
Backup keybag itself is protected with a key (0x835) derived from the iPhone hardware key 
(UID key). So, in order to decrypt the keychain, you need to extract the key 0x835 from the 
device using the demo_brutef orce .py techniques explained in Chapter 4, Data 
Acquisition from iOS Devices. 

Another option is to use a commercial tool, such as Elcomsoft Phone Breaker's Explore 
Keychain feature, which provides access to the keychain file if the user's passcode is known. 
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Elcomsoft Phone Breaker 


■JSV You are trying to view keychain from an unencrypted backup. Due to the 
way keychain data is encrypted this is only possible if you know security 
key of the device that produced the backup. Do you know this key? 


Yes 


No 


Elcomsoft Phone Breaker - unencrypted backup explore keychain 


The tool will then prompt the examiner to enter the passcode to access the device, not the 
passcode for a backup file since the backup is unencrypted. 


Explore Keychain 


Backup - E:\611e51eaac46cc299 ... 25fad36adl3fc2\Manifest.plist 

Device Name - Heather Mahalik's Phone Product type - iPhone 5S (GSM) Phone number - ( I I M, 
ICCID - 8' IMEI - 35* Hi ■ P Serial number - DNB ■ ■ 

Backup date - 2015-05-06T00:09:04-04:00 Backup protection - Not encrypted 


Security key 



Explore 


Elcomsoft Phone Breaker - accessing the keychain 
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Encrypted backup 

iTunes provides an option for users to encrypt their backups using a password. Forensic 
examiners may elect to create an encrypted backup to protect the evidence or to gain access 
to data that is otherwise inaccessible if the backup is not encrypted. For example, e-mail and 
passwords will not be extracted if the backup is not encrypted. It is pertinent that the 
examiner document the password should encryption be used. 

To create an encrypted backup, perform the following steps: 

1. Connect the iOS device to the forensic workstation using the appropriate Apple 
cable. 

2. On the forensic workstation, launch iTunes. 

3. Click on the iPhone icon displayed in the upper-left corner of the iTunes 
interface. It displays the iPhone summary page. 

4. In the iPhone summary page, select the This computer checkbox and select 
the Encrypt iPhone backup option. Selecting the option prompts you to enter a 
password, as shown in the following screenshot. 



iTunes - encrypting the backup file (1) 

5. Set a password and click on the Set Password button. It creates an encrypted 
backup. 
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Set Password 

Enter a password to protect your iPhone backup. 

Password: •••• 

Verify Password: ••••! 

Q Remember this password in my keychain 

Cancel 


Set Password 


iTunes - Encrypting the backup file (2) 

If a backup is password-protected, the password is set on the device itself and stored in the 
keychain file. Also, whenever the device is connected to iTunes, it automatically chooses the 
Encrypt iPhone backup option regardless of whether the users own a copy of iTunes being 
used on their computer or someone else's. So, even if you have access to the suspect's 
iPhone, you cannot produce an unencrypted backup unless you know the backup 
password. This includes when attempting to create a forensic acquisition of the device, 
unless physical acquisition is supported. 

Extracting encrypted backups 

For encrypted backups, the backup files are encrypted using the AES25 6 algorithm in the 
CBC mode, with a unique key and a null IV (initialization vector). The unique file keys are 
protected with a set of class keys from the Backup keybag. The class keys in the Backup 
keybag are protected with a key derived from the password set in iTunes through 10,000 
iterations of PBKDF2 (Password-Based Key Derivation Function 2). Both open source and 
commercial tools provide support for encrypted backup file parsing if the password is 
known. Some tools won't even prompt for a password, which make them useless in a 
forensic investigation. Other tools will attempt to crack the password. 
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Decrypting the keychain 

Encrypted backup files can be cracked using brute force attacks in both command line and 
GUI tools. For encrypted backups, the keychain items protected with the ThisDeviceOnly 
data protection class are encrypted using a set of class keys that are protected with the 
key 0x835. All other keychain items are encrypted using a set of class keys that are 
protected with a password set in iTunes. If you want to extract ThisDeviceOnly protected 
items, you need to extract a key 0x835 from the device using the demo_bruteforce . py 
techniques explained in Chapter 4, Data Acquisition from iOS Devices. 


Elcomsoft Phone Breaker 

Elcomsoft Phone Breaker is a GPU-accelerated commercial tool from Elcomsoft developed 
for the Windows platform. The tool can decrypt an encrypted backup file when the backup 
password is not available. The tool provides an option to launch a password brute-force 
attack on the encrypted backup if the backup password is not available. Elcomsoft Phone 
Breaker tries to recover the plain-text password that protects the encrypted backup using 
dictionary and brute-force attacks. Passwords, which are relatively short and simple, can be 
recovered in a reasonable time. But if the backup is protected with a strong and complex 
password, breaking it can take forever. 

To brute force the backup password, perform the following steps: 

1. Launch the Elcomsoft Phone Breaker tool and the tool's main screen will appear, 
as shown in the following screenshot: 
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Elcomsoft Phone Breaker - Password Recovery Wizard 

2. Navigate to Password Recovery Wizard I Choose Source I iOS device backup. 

Navigate to the backup file you want to crack and select the Manifest .plist 
file. 

3. Configure the brute-force pattern in the Attacks section and click on the Start 
button to start the brute force attack. If the brute force attack is successful, the tool 
displays the password on the main screen. 
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Elcomsoft Phone Breaker-password dictionary attack 


Working with iCIoud backups 

iCloud is a cloud storage and cloud computing service by Apple launched in October 2011. 
The service allows users to keep data such as calendars, contacts, reminders, photos, 
documents, bookmarks, applications, notes, and more in sync across multiple compatible 
devices (iOS devices running with iOS 5 or later, computers with Mac OS X 10.7.2 or later, 
and Microsoft Windows) using a centralized iCloud account. The service also allows users 
to wirelessly and automatically back up their iOS devices to iCloud. iCloud also provides 
other services, such as Find My iPhone (to track a lost phone and wipe it remotely). Find 
My Friends(to share locations with friends and notify the user when a device arrives at a 
certain location), and so on. 

Signing up with iCloud is free and simple to do with an Apple ID. When you sign up for 
iCloud, Apple grants you access to 5 GB of free remote storage. If you need more storage, 
you can purchase the upgrade plan. To keep your data secure, Apple forces users to choose 
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a strong password when creating an Apple ID to use with iCloud. The password must have 
a minimum of eight characters, a number, an uppercase letter, and a lowercase letter. 

iOS devices running on iOS 5 and later allow users to back up the device settings and data 
to iCloud. Data backed up includes photos, videos, documents, application data, device 
settings, messages, contacts, calendar, e-mail, keychain, and so on. You can turn on iCloud 
backup on your device by navigating to Settings I iCloud, as shown in the following 
screenshot. iCloud can automatically back up your data when your phone is plugged in, 
locked, and connected to Wi-Fi. This is to say, iCloud backups represent a fresh and near 
real-time copy of information stored on the device, as long as space is available to create a 
current backup. 
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You can also initiate an iCloud backup from a computer by connecting the device to iTunes 
and choosing the iCloud option. iCloud backups are incremental; that is, once the initial 
iCloudbackup is completed, all the subsequent backups only copy the files that are changed 
on the device. iCloud secures your data by encrypting it when it is transmitted over the 
Internet, storing it in an encrypted format on the server, and using secure tokens for 
authentication. 

Apple's built-in apps (for example, e-mail and Contacts) use a secure token to access iCloud 
services. Using secure tokens for authentication eliminates the need to store the iCloud 
password on devices and computers. 

Extracting iCloud backups 

Online backups stored on the iCloud are commonly retrieved when the original iOS device 
is damaged, upgraded, or lost. To extract a backup from iCloud, you must know the user's 
Apple ID and password. With the known Apple ID and password, you can log on to 
www. icloud. com and get access to contacts, notes, e-mail, calendar, photos, reminders, and 
more. To extract the complete backup from iCloud, you can use Elcomsoft Phone Breaker. 
As iCloud is not the fastest cloud storage, downloading a large backup with Elcomsoft 
Phone Breaker can take hours and may not be successful. To speed up the investigation, the 
tool provides an option to download selected files. 

To extract the iCloud backup, perform the following steps: 

1. Launch Elcomsoft Phone Breaker. 

2. Navigate to Tools I Apple I Download backup from iCloud. You are prompted 
to sign in with your Apple ID and password. 

3. Successfully signing in with your Apple ID lists the available device backups that 
can be downloaded, as shown in the following screenshot: 
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All tools 


Download backup from iCIoud 


Heather Mahalik (1345699674) - hmahalik@gmail.com 


Change user 


Device 
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mi 
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iCIoud backup options on the iPhone 

4. Select the backup you need and click on Download. You are prompted for a 
destination directory to save the extracted files into a number of domain 
directories by restoring the original filenames. The tool also provides an option to 
download the backup without restoring the original filenames so that you can 
use third-party software for analysis. 

For iCIoud backups, the keychain file contents are encrypted with a set of class keys in the 
Backup keybag. The Backup keybag itself is protected with a key (0x835) derived from the 
iPhone hardware key (UID key). You can follow the techniques explained in the preceding 
sections to decrypt the keychain from the extracted iCloudbackup. 
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Summary 

iOS device backups contain essential information that may be your only source of evidence. 
Information stored in iOS backups includes photos, videos, contacts, e-mail, call logs, user 
accounts and passwords, applications, device settings, and so on. This chapter covered 
techniques to create backup files and retrieve data from iTunes and iCloud backups 
including encrypted backup files, wherever possible. Chapter 6, iOS Data Analysis and 
Recovery, goes further into the forensic investigation by showing the examiner how to 
analyze the data recovered from the backup files. Areas containing data of potential 
evidentiary value will be explained in detail. Chapter 6, iOS Data Analysis and Recovery, 
will then teach you how to analyze the data pulled from Chapter 4, Data Acquisition from 
iOS Devices, and artifacts pulled from backup files as discussed in this chapter. 
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Techniques 

Using any of the screen lock bypass techniques explained in Chapter 8, Android Forensic 
Setup and Pre Data Extraction Techniques, an examiner can try to access a locked device. Once 
the device is accessible, the next task is to extract the information present on the device. This 
can be achieved by applying various data extraction techniques to the Android device. This 
chapter will help you to identify the sensitive locations present on an Android device and 
explain various logical and physical techniques that can be applied to the device in order to 
extract the necessary information. 

In this chapter, we will cover the following topics: 

• Logical data extraction using ADB pull, ADB backup, ADB dumpsys, and content 
providers 

• Physical extraction, which covers imaging an Android device and SD card, JTAG, 
and chip-off techniques 


Data extraction techniques 

Data residing on an Android device may be an integral part of civil, criminal, or internal 
investigations done as part of a corporate company's internal probe. While dealing with 
investigations involving Android devices, the forensic examiner needs to be mindful of the 
issues that need to be taken care of during the forensic process; this includes determining 
whether root access is permitted (via consent or legal authority) and what data can be 
extracted and analyzed during the investigation. For example, in a criminal case involving 
stalking, the court may only allow for SMS, call logs, and photos to be extracted and 
analyzed on the Android device belonging to the suspect. In this case, it may make the most 
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sense to logically capture just those specific items. However, it is best to obtain full physical 
data extraction of the device and only examine the areas admissible by the court. You never 
know where your investigation may lead and it is best to obtain as much data from the 
device immediately rather than wish you had a full image should the scope of consent 
change. 

The data extraction techniques on an Android device can be classified into three types: 

• Manual data extraction 

• Logical data extraction 

• Physical data extraction 

As described in Chapter 1 , Introduction to Mobile Forensics, manual extraction involves 
browsing through the device normally and capturing any valuable information. While 
logical extraction deals with accessing the file system, physical extraction is about extracting 
a bit-by-bit image of the device. The extraction methods for each of these types will be 
described in detail in the following sections. 

O Some methods may require the device to be rooted in order to fully access 
the data. Each method has different implications, and their success rates 
will depend on the tool, the method used, and the device's make and 
model. 


Manual data extraction 

This method of extraction involves the examiner utilizing the normal user interface of the 
mobile device to access content present in the memory. The examiner will browse through 
the device normally by accessing different menus to view the details such as call logs, text 
messages, and IM chats. The content of each screen is captured by taking pictures and can 
be presented as evidence. The main drawback with this type of examination is that only the 
files that are accessible via the operating system (in UI mode) can be investigated. Care 
must be taken when manually examining the device as it's easy to press the wrong button 
and erase or add data. Manual extraction should be used as the last resort to verify findings 
extracted using one of the other methods. Certain circumstances may warrant the examiner 
to conduct manual examination as the first step. This may include cases of life or death 
situations or missing persons where a quick scan of the device may lead the police to the 
individual. 
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Logical data extraction 

Logical data extraction techniques extract the data present on the device by interacting with 
the operating system and by accessing the file system. These techniques are significant 
because they provide valuable data, work on most devices, and are easy to use. Once again, 
the concept of rooting comes into the picture while extracting the data. Logical techniques 
do not actually require root access for data extraction. However, having root access on a 
device allows you to access all the files present on a device. This means that some data may 
be extracted on a non-rooted device while root access will open the device and provide 
access to all the files present on the device. Hence, having root access to a device would 
greatly influence the amount and kind of data that could be extracted through logical 
techniques. The following sections explain various techniques that can be used to extract 
data logically from an Android device. 

ADB pull data extraction 

As seen earlier, adb is a command-line tool that helps you communicate with the device to 
retrieve information. Using adb, you can extract data from all the files on the device or only 
the relevant files in which you are interested. 

To access an Android device through adb, it's necessary that the USB debugging option is 
enabled. From Android 4.2.2, due to secure USB debugging, the host connecting to the 
device should also be authorized. If the device is locked and USB debugging is not enabled, 
try to bypass the screen lock using the techniques mentioned in Chapter 8, Android 
Forensic Setup and Pre Data Extraction Techniques. 

As a forensic examiner, it's important to know how the data is stored on the Android device 
and to understand where important and sensitive information is stored so that the data can 
be extracted accordingly. Application data often contains a wealth of user data that may be 
relevant to the investigation. All files pertaining to applications of interest should be 
examined for relevance, as will be explained in Chapter 10, Android Data Analysis and 
Recovery. The application data can be stored in one of the following locations: 

• Shared preferences: This stores data in key-value pairs in a lightweight XML 
format. Shared preference files are stored in the shared_pref folder of the 
application /data directory. 

• Internal storage: This stores data that is private and is present in the device's 
internal memory. Files saved to the internal storage are private and cannot be 
accessed by other applications. 

• External storage: This stores data that is public in the device's external memory, 
which does not usually enforce security mechanisms. This data is available 
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in the /sdcard directory. 

• SQLite database: This data is available in 
the /data/data/PackageName/ database. They are usually stored with the . db 
file extension. The data present in a SQLite file can be viewed using a SQLite 
browser (http : //sourceforge . net/pro jects/SQLitebrowser/) or by 
executing the necessary SQLite commands on the respective files. 

Every Android application stores data on the device using any of the preceding data 
storage options. So, the Contacts application would store all the information about the 
contact details in the /data /data folder under its package name. Note that /data /data is 
a part of your device's internal storage where all the apps are installed under normal 
circumstances. Some application data will reside on the SD card and in the /data/data 
partition. Using adb, we can pull the data present in this partition for further analysis using 
the adb pull command. Once again, it's important to note that this directory is only 
accessible on a rooted phone. 

On a rooted phone, the adb pull command on the databases folder of the Dropbox app 
can be executed as follows: 


C:\android-sdk\platform-tools>adb.exe pull /data/data/com. dropbox. android/databases C:\temp 
pull: building file list... 

pull: /data/data/com. dropbox. android/databases/prefs.db-journal -> C:\temp/prefs.db- journal 
pull: /data/data/com. dropbox. android/databases/prefs.db -> C:\temp/prefs.db 
pull: /data/data/com. dropbox. android/databases/db.db-journal -> C:\temp/db.db- journal 
pull: /data/data/com. dropbox. android/databases/db.db -> C:\temp/db.db 
4 files pulled. 0 files skipped. 

1753 KB/S (140352 bytes in 0.078s) 


Similarly, on a rooted phone, the entire /data folder can be pulled in this manner. As 
shown in the following screenshot, the complete /data directory on the Android device 
was copied to the local directory on the machine. The entire data directory was extracted in 
97 seconds. The extraction time will vary depending on the amount of data residing 

in/data. 
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The /data directory extracted to a forensic workstation 


On a non-rooted device, a pull command on the /data directory does not extract the files as 
shown in the following output, since the shell user does not have permission to access those 


files: 


C : \android-sdk\platform-tools>adb . exe pull /data C:\temp 
pull : building -File list . . . 

0 -files pulled. 0 -files skipped. 


The data copied from a rooted phone through the preceding process maintains its directory 
structure, thus allowing an investigator to browse through the necessary files to gain access 
to the information. By analyzing the data of the respective applications, a forensic expert 
can gather critical information that can influence the outcome of the investigation. Note that 
examining the folders natively on your forensic workstation will alter the dates and times of 
the content. The examiner should make a copy of the original output to use for a date/time 
comparison. 
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Using SQLite Browser to view the data 

SQLite Browser is a tool that can help during the course of analyzing the extracted data. 
SQLite Browser allows you to explore the database files with the following extensions: 

. sqlite, . sqlite3, . sqlitedb, . db, and . db 3. The main advantage of using SQLite 
Browser is that it shows the data in a table form. Navigate to File I Open Database to open 
a . db file using SQLite Browser. As shown in the following screenshot, there are three 
tabs: Database Structure, Browse Data, and Execute SQL. The Browse Data tab allows you 
to see the information present in different tables within the . db files. 

We will be mostly using this tab during our analysis. Alternately, Oxygen Forensic SQLite 
Database Viewer can also be used for the same purpose. Recovering deleted data from 
database files is possible and will be explained in Chapter 10, Android Data Analysis and 
Recovery. 



SQLite Browser 

The following sections throw light on identifying important data and manually extracting 
various details from an Android phone. 


Extracting device information 

Knowing the details of your Android device, such as the model, version, and more, will aid 
your investigation. For example, when the device is physically damaged and prohibits the 
examination of the device information, you can grab the details about the device by viewing 
the build. prop file present in the /system folder, as follows: 
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root@android : /system # cat build. prop 

# begin build properties 

# autogenerated by buildinfo.sh 
ro . build . id=lZ054K 

ro . build . display . id=3Z054K . 1H4 

ro . build . version . incremental = I ^HVi"H4 

ro . build . version . sdk=16 

ro . build . version . codename=REL 

ro . build . version . release=4 .1.2 

ro. build. date=Tue Sep 17 17:26:31 KST 2013 

ro. build . date. utc=1379406391 

ro. build .type=user 

ro . build . user=dpi 

ro . build . host=DELL224 

ro. build . t ags=release- keys 

ro . product . model=GT-I9300 

ro . product . brand=samsung 

ro . product . name=m0xx 

ro . product . device=m0 

ro . product . board=smdk4xl2 

ro . product . cpu . abi=armeabi- v7a 

ro . product . cpu . abi2=armeabi 

ro . product_ship=true 

ro . product . manuf acturer=samsung 

ro . product . locale . language=en 

ro . product . locale . region=GB 

ro . wifi . channels= 

ro . board . platform=exynos4 


Extracting call logs 

Accessing the call logs of a phone is often required during the investigation to confirm 
certain events. The information about call logs is stored in the contacts2 . db file located at 
/ data/ data/ com . android . providers . contacts/ databases/. As mentioned earlier, 
you can use SQLite Browser to see the data present in this file after extracting it to a local 
folder on the forensic workstation. As shown in the following screenshot, using the adb 
pull command, the necessary . db files can be extracted to a folder on the forensic 
workstation, as shown in the following screenshot: 
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The COnt act s2 . db file copied to a local folder 

Note that applications used to make calls can store call log details in the respective 
application folder. All communication applications must be examined for call log details, as 
follows: 

C : \android-sdk-windows\platform-tools>adb . exe pull 
/data/data/com. android . providers . contacts C : \temp 


bull : / data/data/com . android . providers . contacts/databases/contacts2 . db-mj FB7EA79BB - > C : \temp/ databases/contacts2 . db-mj FB7EA79BB 

Hill: /data/data/com. android. providers .contacts/databases/contacts2. db-mj 7DE1FC9E3 -> C : \temp/databases/contacts2.db-mj7DElFC9E3 

Dull : /data/ data/ com . android . providers . contacts/ databases/ contacts2 . db-mj 2151EE924 - > C : \temp/ databases/ contact s2 . db-mj 2151EE924 

Dull : / data/ data/ com . android . providers . contacts/databases/contacts2 . db-mj ABC96A935 - > C : \temp/ databases/ contacts2 . db-mjABC96A935 

Dull: /data/data/com.android.providers.contacts/databases/profile.db-shm -> C:\temp/databases/profile.db-shm 

Dull: /data/data/com. android. providers. contacts/databases/prof ile.db-wal -> C:\temp/databases/profile.db-wal 

Dull: /data/data/com. android. providers. contact s/databases/ prof ile.db -> C:\temp/databases/profile.db 

Dull: /data/data/com.android.providers.contacts/databases/contacts2.db-shm -> C:\temp/databases/contacts2.db-shm 

Dull: /data/data/com. android. providers. contacts/databases/contacts2.db-wal -> C:\temp/databases/contacts2.db-wal 

Dull : / data/ data/ com . android . providers . contacts/databases/contacts2 . db - > C : Ytemp/ databases/contacts2 . db 

Dull : /data/data/com. android .providers. contacts/ shared_prefs/ com. android. providers .contact s_pref erences .xml -> C : \temp/ shared_prefs/com.android 
,, ences .xml 

Dull: /data/data/com. android. providers. contacts/sharedpref s/Contact slIpgradeReceiver. xml -> C: Xtemp/sharedprefs/ContactsUpgradeReceiver.xml 
Dull: /data/data/com. android. providers. contacts/files/photos/2446 -> C : \temp/files/photos/2446 
576 files pulled. 0 files skipped. 

1820 KB/s (13795864 bytes in 7.398s) 


Now, open the contacts2 . db file using SQLite Browser (by navigating to File I Open 
Database) and browse through the data present in different tables. The calls table present 
in the contact s2 . db file provides information about the call history. The following 
screenshot highlights the call history along with the name, number, duration, and date: 
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Extracting SMS/MMS 

During the course of investigation, a forensic examiner may be asked to retrieve the text 
messages that are sent by and delivered to a particular mobile device. Hence, it is important 
to understand where the details are stored and how to access the data. The mms sms . db file 
which is present under 

the / data/ data/ com. android . providers . telephony/ databases location contains the 
necessary details. As with call logs, the examiner must ensure that applications capable of 
messaging are examined for relevant message logs, as follows: 


::\android-sdk\platform-tools>adb.exe pull /data/data/com. android. providers. telephony C:\temp 
Dull: building file list... 

Dull : /data/data/com . android . providers . telephony/databases/telephony . db- journal - > C : \temp/databases/telephony . db- journal 

Dull : /data/data/com . android . providers . telephony/databases/telephony . db - > C : \temp/databases/telephony . db 

Dull : /data/data/com . android . providers . telephony/databases/nwk_info . db- journal - > C : \temp/databases/nwk_inf o . db- journal 

Dull : /data/data/com . android . providers . telephony/databases/nwkinf o . db - > C : \temp/databases/nwk_inf o . db 

Dull: /data/data/com.android.providers.telephony/databases/mmssms.db-shm -> C:\temp/databases/mmssms.db-shm 

Dull : /data/data/com . android . providers . telephony/databases/ mmssms . db-wal - > C : Ytemp/databases/mmssms . db-wal 

Dull : /data/data/com . android . providers . telephony/databases/mmssms . db - > C : Ytemp/databases/mmssms . db 

Dull : /data/data/ com . android . providers . telephony/shared_pref s/pref erred-apn . xml - > C : \temp/shared_pref s/ pref erred -apn . xml 
Dull: /data/data/com. android. providers. telephony/optable.db -> C:\temp/optable.db 
? files pulled. 0 files skipped. 

3096 KB/s (6193778 bytes in 1.953s) 


The phone number can be seen under the address column and the corresponding text 
message can be seen under the body column, as shown in the following screenshot: 



The calls table in the COntacts2 . db file 
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Extracting browser history 

Extracting browser history information is one task that is often required to be reconstructed 
by a forensic examiner. Apart from the default Android Browser, there are different 
browser applications that can be used on an Android phone, such as Firefox Mobile, Google 
Chrome, and so on. All of these browsers store their browser history in the SQLite . db 
format. For our example, we are extracting data from the default Android browser to our 
forensic workstation. This data is located at /data/data/com. android. browser. The file 
named browser2 . db contains the browser history details. The following screenshot shows 
the browser data as represented by Oxygen Forensic SQFite Database Viewer. Note that the 
trial version will hide certain information. 
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The brOWSer2 . cLb file in Oxygen Forensic SQLite Viewer 
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Analysis of social networking/IM chats 

Social networking and IM chat applications such as Facebook, Twitter, and WhatsApp 
reveal sensitive data, which could be helpful during the investigation of any case. The 
analysis is pretty much the same as with any other Android applications. Download the 
data to a forensic workstation and analyze the . db files to find out if you can unearth any 
sensitive information. For example, let's look at the Facebook application and try to see 
what data can be extracted. First, we extract the /data/data/com. facebook . katana 
folder and navigate to the databases folder. The fb . db file present under this folder 
contains the information that is associated to the user's account. The f riends_data table 
contains information about the friend's names along with their phone numbers, e-mail IDs, 
and date of birth, as shown in the following screenshot. Similarly, other files can be 
analyzed to find out if any sensitive information can be gathered. 
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The f b . db file in SQLite browser 


Similarly, by analyzing the data present in the /data /data folder, information about geo- 
location, calendar events, user notes, and more can be grabbed. 
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ADB backup extraction 

Starting from Android 4.0, Google implemented the adb backup 

functionality, which allows users to back up application data to a computer using the adb 
tool. This process does not require root access and hence can be very useful during forensic 
examination. But the main drawback is that it does not back up every application installed 
on the device. The backup feature is application dependent as the owner of the application 
can choose to allow backups. Backups are allowed by default, but the developer can disable 
it if he wants to. Hence, most of the third-party apps have this enabled, and thus the adb 
backup command will work for them. Here is the syntax for the adb backup command: 

adb backup [-f <file>] [-apk | -noapk] [-shared | -noshared] [-all] 

[-system | nosystem] [<packages. . .>] 

• -f : This is used to choose where the backup file will be stored. If not specified, it 
defaults to backup . ab in the present working directory. 

• [ -apk | noapk ] : This is used to choose whether or not to back up the . apk file. 
The default is -noapk. 

• [ -obb | -noobb ] : This is used to choose whether or not to back up the . obb (APK 
expansion) files. It defaults to -noobb. 

• [-shared | -noshared] : This is used to choose whether or not to back up data 
from shared storage and the SD card. The default is -noshared. 

• [-all]: This includes all applications for which backups are enabled. 

• [-system | -nosystem] : This is used to choose whether or not to include system 
applications. It defaults to -system. 

• [ <packages> ] : This is used to list a specific package name to be backed up. 

Once the device is connected to the workstation and adb is able to access it, run the adb 
backup command, as shown in the following screenshot: 


t:\android-sdk\platfona-toolsxadb.exe backup -shared -all 
Now unlock your device and confina the backup operation. 


The adb back up command 
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Once the command is run, the user then needs to approve the permission on the device, as 
shown in the following screenshot. For this reason, if the device is screen locked, it's not 
possible to take a backup. 


O * y XS+Al a 12:45 

1*1 Full backup 


A full backup of all data to a connected desktop 
computer has been requested. Do you want to 
allow this to happen? 

If you did not request the backup yourself, do not 
allow the operation to proceed. 


Please enter your device encryption password 
below This will also be used to encrypt the backup 
archive. 


Do not back up 

Back up my data 

<r ~ID 

I — 1 cf=P 


Backup permission on the device 

An Android backup file is stored as a . ab file and by default it is stored in the platform- 
tools folder of the Android SDK. There are free tools, such as Android Backup Extractor, 
that can convert the . ab file into a . tar file, which can then be viewed. Android Backup 
Extractor can be downloaded 

from https : / / sourceforge . net/pro jects/adbextractor/. This tool is a Java-based 
application, so ensure that Java is installed on the workstation before using the tool. To 
convert the backup file to tar format, issue the following command: 

java -jar abe.jar unpack backup. ab backup. tar 
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This will automatically create a file with the .tar extension, which can then be viewed 
easily using Archive tools such as WinRAR or 7Zip. However, note that if the password 
was entered on the device when the backup was created, the file would be encrypted and 
hence the examiner needs to provide the password as an argument in the preceding 
command. The backup file contains two main folders -apps and shared. The apps folder 
contains all the information that is present under /data/ data for the applications included 
in the backup. The shared folder contains all the data present on the SD card. 


ADB dumpsys extraction 

The adb dumpsys command allows you to gather information about services and 
applications running on the system. The adb shell dumpsys command gives diagnostic 
output for all system services. The dumpsys command does not require root privileges to be 
executed and requires only USB debugging to be enabled as with any other adb command. 
As shown in the following screenshot, to see the list of all services that you can use with 
dumpsys, run the adb shell service list command: 


C:\android-sdk\platform-tools>adb.exe shell service list 
Found 111 services: 

0 SYSSCOPE : [com. sec . android . app. sysscope . service . ISysScopeService] 

1 sip: [android.net .sip. ISipService] 

2 phoneext: [com. android . internal .telephony . ITelephonyExt ] 

3 phone: [com. android. internal. telephony. ITelephony] 

4 com. orange . authentication . simcard : [com. orange . authentication . simcard . ISimCardAuthenticationSer vice] 

5 iphonesubinfo : [com. android . internal .telephony . IPhoneSublnfo] 

6 simphonebook: [com. android . internal .telephony . IIccPhoneBook] 

7 isms: [com. android. internal. telephony. ISms] 

8 nfc: [android. nfc . INfcAdapter] 

9 FMPlayer: [com. Samsung. media. fmradio. internal. IFMPlayer] 

10 motion_recognition : [android . hardware . motion . IMotionRecognitionService] 

11 samsung.facedetection_service: [com. sec . android .facedetect ion . IFaceDetectionService] 

12 voip: [android.os.IVoIPInterface] 

13 commontime_management : [] 

14 mini_mode_app_manager : [com . sec . android . app . minimode . manager . IMiniModeAppManager] 

15 tvoutservice : [android. os . ITvoutService] 

i c - ^ i u: i . - - 


The dumpsys service list command 

Analyzing certain dumpsys services, such as Wi-Fi, user, notification and so on, can be 
helpful in certain scenarios. Here are some of the interesting cases where running the 
dumpsys command could be helpful during forensic analysis. 
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The dumpsys iphonesubinf o service can be used to get information about device ID or 
the IMEI number, as shown in the following screenshot. 


t : \android- sdk\platf orm- tools>adb . exe shell dumpsys iphonesubinfo 
Phone Subscriber Info: 

Phone Type = GSM 

Device ID = 3537430' T.6486 


The dumpsys command showing the IMEI number 


The dumpsys wifi service gives information about Wi-Fi points accessed by the user. It 
shows the SSIDs of the connections which have been saved. This information can be used to 
pin down the user to a particular location. Here is the adb dumpsys command which gives 
this information: 


C:\android-sdk\platform-toolsyadb.exe shell dumpsys wifi 
Wi-Fi is enabled 
Stay-awake conditions: 6 

Internal state: 

current HSM state: ConnectedState 

mLinkProperties InterfaceName : wlan9 LinkAddresses : [192.168.0.106/24,] 

mWifilnfo , MAC: 88:39:8a:f3:fl:d5, Supplicant state: COMPLETED, RSSI: - 

mDhcpInfoInternal addr: 192.168.0.106/24 mRoutes: 0.0. 0.0/0 -> 192.168.01 

mNetworklnfo Networklnfo: type: WIFI[], state: CONNECTED/CONNECTED, reas 

mLastSignalLevel 2 

mLastBssid 60 : e3 : 27 : be : d5 : 30 

mLastNetworkld 1 

mReconnectCount 0 

mlsScanMode false 

Supplicant status 

bssid=60 : e3 : 27 : be : dS : 30 

ssid=Roro 

id=l 


The dump S y S command showing last connected Wi-Fi details 


The dumpsys usagestats service gives information about recently used applications 
along with their date of usage. For example, the following screenshot shows that no apps 
were used on 02-01-2016; but on 01-31-2016, the Google Chrome browser was used and 
there was also an attempt to back up the phone data. 
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C:\android-sdk\platform-tools>adb.exe shell dumpsys usagestats 
Date: 20160129 (old data version) 

Date: 20160131 

android: 1 times, 7 ms 

com. android. server. ShutdownActivity: 1 starts 
com. android. chrome: 1 times, 172801 ms 

com. google. android. apps. chrome. Main: 1 starts 

org. chromium. chrome. browser. ChromeTabbedActivity: 1 starts, 500-750ms=l 
com. sec. android. app. launcher: 4 times, 509170 ms 

com. android. Iauncher2. Launcher: 4 starts, 2000-3000ms=l 
com. android. backupconfirm: 2 times, 77425 ms 

com. android. backupconfirm.BackupRestoreConfirmation: 2 starts, 500-750ms=l 
Date: 20160201 

android: 0 times, 3052 ms 


The dump S y S command showing recently used apps 

Depending on the case being investigated, the forensic analyst needs to figure out if any of 
the dumpsys commands can be of use. Running a dumpsys command immediately after a 
device seizure can be extremely helpful later on. By running the adb shell dumpsys 
command, you can record all the dumpsys service information. 


Using content providers 

In Android, the data of one application cannot be accessed by another application under 
normal circumstances. However, Android provides a mechanism through which data can 
be shared with other applications. This is precisely achieved through the use of content 
providers. Content providers present data to external applications in the form of one or 
more tables. These tables are no different from the tables found in a relational database. 
They can be used by the applications to share data usually through the URI addressing 
scheme. They are used by other applications that access the provider using a provider-client 
object. During the installation of an app, the user determines whether or not the app can 
gain access to the requested data (content providers). For instance, contacts, SMS/MMS, 
calendar, and so on, are examples of content providers. 

Hence, by taking advantage of this, we can create an app that can grab all the information 
from all the available content providers. This is precisely how most of the commercial 
forensic tools work. The advantage of this method is it can be used on both rooted and non- 
rooted devices. For our example, we use AFLogical, which takes advantage of the content 
provider mechanism to gain access to the information. This tool extracts the data and saves 
it to an SD card in CSV format. The following steps extract the information from an 
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Android device using AFLogical Open Source Edition 1.5.2: 

1. Download AFLogical OSE 1.5.2 

from https : // git hub . com/ viaf orensics/ android- 
forensics /downloads. 

O The AFLogical LE edition is capable of extracting a large set of information 
and requires registration with viaForensics using an active law 
enforcement or government agency e-mail. AFLogical OSE can pull all 
available MMSs, SMSs, contacts, and call logs. 

2. Ensure that USB debugging mode is enabled and connect the device to the 
workstation. 

3. Verify that the device is identified by issuing the following command: 


C : \android-sdk\platform-tools>adb . exe devices 
List of devices attached 
kdf!6ac3110MM device 


4. Save the AFLogical OSE app in the home directory and issue the following 
command to install it on the device: 


C : \andnoid -sdk\platform- tools >adb . exe install AF Logical -0SE_1 .5.2. apk 
1798 KB/s (28794 bytes in 0.015s) 

pkg: /data/local/tmp/AFLogical-OSE_l .5.2. apk 

Success 


5. Once the application is installed, you can run it directly from the device and click 
on the Capture button present at the bottom of the app, as shown in the following 
screenshot: 
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The AFLogical OSE app 

6. The app starts extracting data from the respective content providers, and once the 
process is complete, a message will be displayed, as shown in the following 
screenshot: 



Message displayed after the extraction is complete 

7. The extracted data is saved to the SD card of the device in a directory 
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named forensics. The extracted information is stored in CSV files, as shown in 
the following figure. The CSV files can be viewed using any editor. 
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Files extracted using AFLogical OSE 

8. The info . xml file present in the same directory provides information about the 
device including the IMEI number, IMSI number. Android version, information 
about installed applications, and so on. 

However, note that third-party apps 1 installation should be allowed (by selecting the 
Unknown Sources option) on the device for this to work. Other tools that can help during 
investigation to logically extract data will be covered in Chapter 1 1 , Android App Analysis, 
Malware and Reverse Engineering. 


Physical data extraction 

Physical extraction refers to the process of obtaining an exact bit-by-bit image of the device. 
It is important to understand that a bit-by-bit image is not similar to copying and pasting 
the contents on the device. If we copy and paste the contents on a device, it will only copy 
the available files such as visible files, hidden files, and system-related files. This method is 
considered as a logical image. With this method, deleted files and files that are not 
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accessible are not copied by the copy command. Deleted files can be recovered (based on 
the circumstances) using certain techniques, which we will see in the following chapters. 
Unlike logical extraction, physical extraction is an exact copy of the device's memory and 
includes more information such as the slack space, unallocated space, and so on. 

Android data extraction through physical techniques is commonly performed using the dd 
command, while other advanced techniques such as JTAG and chip-off are also available 
but are usually hard to implement and require great precision and experience to try them 
on real devices during the course of an investigation. JTAG and chip-off techniques are 
covered in detail in the following sections. However, extracting data through the dd 
command requires root access. The following sections provide an overview of various 
techniques to perform physical extraction. 

Imaging an Android Phone 

Imaging a device is one of the most important steps in mobile device forensics. When 
possible, it's imperative to obtain a physical image of the Android device before performing 
any techniques to extract the data directly from the device. In forensics, this process of 
obtaining a physical acquisition is commonly called imaging the device. The terms physical 
image, forensic image, or raw image are often used to refer to the image captured through 
this process. Let's first revisit how imaging is done on a desktop computer as it helps us to 
correlate and realize the problems associated with imaging Android devices. Let's assume 
that a desktop computer, which is not powered on, is seized from a suspect and sent for 
forensic examination. In this case, a typical forensic examiner would remove the hard disk, 
connect it to a write blocker and obtain a bit-by-bit forensic image using any of the available 
tools. The original hard disk is then safely protected during the forensic imaging of the data. 
With an Android device, all the areas that contain data cannot be easily removed. Also, if 
the device is active at the time of receiving it for examination, it is not possible to analyze 
the device without making any changes to it because any interaction would change the state 
of the device. 

An Android device may have two file storage areas, internal and external storage. Internal 
storage refers to the built-in non-volatile memory. External storage refers to the removable 
storage medium such as a micro SD card. However, it's important to note that some devices 
do not have a removable storage medium such as an SD card, but they divide the available 
permanent storage space into internal and external storage. Hence, it's not always true that 
external storage is something that is removable. When a removable SD card is present, a 
forensic image of the memory card has to be obtained. As discussed in Chapter 
7, Understanding Android, these removable cards are generally formatted with the FAT 32 
file system. Some mobile device acquisition methods will acquire the SD card through the 
Android device. This process, while useful, will be slow due to the speed limitations of the 
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USB phone cables. 

Android, by default, does not provide access to the internal directories and system-related 
files. This restricted access is to ensure the security of the device. For instance, the 
/data/data folder is not accessible on a non-rooted device. This folder is especially of 
interest to us because it stores most of the user-created data, and many applications write 
valuable data into this folder. Hence, to obtain an image of the device, we need to root the 
Android device. Rooting a device gives us superuser privileges and access to all the data. It 
is important to realize that this book has been stressing that all the steps taken should be 
forensically sound and should not make changes to the device whenever possible. Rooting 
an Android device will make changes to it and should be tested on any device that the 
examiner has not previously investigated. Rooting is common for Android devices, but 
getting root access could alter the device in a manner that renders the data changed or 
worse yet— wiped. Some Android devices, such as the Nexus 4 and 5, may force the data 
partition to be wiped prior to allowing root access. This negates the need to root the device 
in order to gain access because all the user data is lost during the process. Just remember 
that while rooting provides access to more data when successfully done, it can also wipe the 
data or destroy the phone. Hence, you must ensure that you have consent or legal rights to 
manipulate the Android device prior to proceeding with the root. As rooting techniques 
have been discussed in Chapter 8, Android Forensic Setup and Pre Data Extraction 
Techniques, we will proceed with the example assuming that the device is rooted. 

The following is a step-by-step process to obtain a forensic image of a rooted Android 
device: 


1. Connect the Android device to the workstation and verify that the device is 
identified by issuing the adb devices command, as shown here: 


C : \andnoid -sdk\platform- tools >adb . exe devices 
List of devices attached 
4dfl6ac31iMMM device 


2. Once the adb access is ready, the partitions can be acquired from the Android 
device using the following steps: 

1. Using the dd command: The dd command can be used to create a raw 
image of the device. This command helps us create a bit-by-bit image of the 
Android device by copying low-level data. 
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2. Inserting a new SD card: Insert a new SD card into the device in order to 
copy the image file to this card. Make sure that this SD card is wiped and 
does not contain any other data. 

3. Executing the command: The file system of an Android device is stored in 
different locations within the /dev partition. A simple mount command on a 
Samsung Galaxy S3 phone returns the following output: 


root@android : / # mount 

rootfs / rootfs ro, relatime 0 0 

tmpfs /dev tmpfs rw, nosuid, relatime, mode=755 0 0 

devpts /dev/pts devpts rw, relatime, mode=600 0 0 

proc /proc proc rw, relatime 0 0 

sysfs /sys sysfs rw, relatime 0 0 

none /acct cgroup rw, relatime, cpuacct 0 0 

tmpfs /mnt/asec tmpfs rw, relatime, mode=755,gid=1000 0 0 

tmpfs /mnt/obb tmpfs rw, relatime, mode=755,gid=1000 0 0 

none /dev/cpuctl cgroup rw, relatime, cpu 0 0 

/dev/block/mmcblk0p9 /system ext4 ro,noatime,barrier=l,data=ordered 0 0 
/dev/block/mmcblk0p3 /efs ext4 rw, nosuid, nodev, noatime, barrier=l, journal_asyi 
/dev/block/mmcblk0p8 /cache ext4 rw, nosuid, nodev, noatime, errors=panic, barriei 
/dev/block/mmcblk0pl2 /data ext4 rw, nosuid, nodev, noatime, barrier=l,journal_a! 
/sys/kernel/debug /sys/kernel/debug debugfs rw, relatime 0 0 
/dev/fuse /storage/sdcard0 fuse rw, nosuid, nodev, noexec, relatime, user_id=1023. 


3. From the preceding output, we can identify the blocks where 

the /system, /data, and /cache partitions are mounted. Although it's 

important to image all the files, most of the data is present in the / data 

and / system partitions. When time allows, all partitions should be acquired for 

completeness. Once this is done, execute the following command to image the 

device: 

dd if=/dev/block/mmcblk0pl2 of =/sdcard/tmp . image 

In the preceding example, the data partition of a Samsung Galaxy Sill was used (where i f 
is the input file and of is the output file). 

The preceding command will make a bit-by-bit image of the mmcblk0pl2 file (data 
partition) and copy the image file to an SD card. Once this is done, the dd image file can be 
analyzed using the available forensic software. 
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The examiner must ensure that the SD card has enough storage space to 
contain the data partition image. Other methods are available to acquire 
data from the rooted devices. 


Imaging a memory (SD) card 

There are many tools available that can image a memory card. The following example uses 
WinHex to create a raw disk image of the SD card. The following is a step-by-step process 
to image a memory card using WinHex: 

1. Connecting the memory card: Remove the SD card from the memory slot and 
use a card reader to connect the memory card to the forensic workstation. 

2. Write protect the card: Open the disk using WinHex. Navigate to Options I Edit 
Mode and select write-protected mode, as shown in the following screenshot. 
This is to make sure that the device is write protected and no data can be written 
on it. 


Options Window Help 


•yy 

O 


General- 

Directory Browser... 
Volume snapshot... 
Viewer Programs... 


Data Interpreter... 

Undo- 

Security... 


Edit Mode... 


F5 


Ctrl+F5 

Select Mode (globally) 




(I+F5 


Read-only Mode (=write-protected 


Alt-*- F5 


Default Edit Mode (=editable) 




In-place Mode (=editable) 




Cancel 


Help 


WinHex view of Edit Mode (left) and WinHex Read-only Mode enabled (right) 

3. Calculating the hash value: Calculate the hash value of the memory card to make 
sure that no changes are made at any point during the investigation. Navigate 

to Tools I Compute hash and choose any hashing algorithm. 

4. Creating the image of the disk: Navigate to File I Create Disk Image, as shown 
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in the following screenshot. Select the Raw image option ( . dd) to create an 
image. This completes the imaging of the memory card. 



The WinHex disk image option 

Once a forensic image is obtained using any of the methods described previously, it needs 
to be analysed to extract the relevant information. There are several commercial tools, such 
as Cellebrite, XRY, and so on, that can analyse the image files. Analysing Android images is 
covered in detail in Chapter 1 0 , Android Data Analysis and Recovery. 


Joint Test Action Group 

Joint Test Action Group (JTAG) involves using advanced data acquisition methods, which 
involve connecting to specific ports on the device and instructing the processor to transfer 
the data stored on the device. Using this method, a full physical image of a device can be 
acquired. It is always recommended to first try out the other techniques mentioned earlier, 
as they are easy to implement and require less effort. Examiners must have proper training 
and experience prior to attempting JTAG as the device may be damaged if handled 
improperly. 
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The JTAG process usually involves the following forensic steps: 

1. In JTAG, the device Test Access Ports (TAPs) are used to access the CPU of the 
device. Identifying the TAPs is the primary and most important step. TAPs are 
identified and the connection is traced to the CPU to find out which pad is 
responsible for each function. Although device manufacturers document 
resources about the JTAG schematics of a particular device, they are not released 
for general viewing. A good site for JTAG on an Android device 

is http : / / www . forensics wiki . org/ wiki/ JTAG_Forensics. 

2. Wire leads are then soldered to appropriate connector pins and the other end is 
connected to the device that can control the CPU, as shown in the following 
image (published by www . binaryintel . com). JTAG jigs can be used to forgo 
soldering for certain devices. The use of a jig or JTAG adapter negates the need to 
solder, as it connects the TAPs to the CPU. 



The JTAG setup 
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3. Once the preceding steps are complete, power must be applied to boot the CPU. 
The voltage that must be applied depends on the specifications released by the 
hardware manufacturer. Do not apply a voltage beyond the number mentioned 
in the specification. 

4. After applying the power, a full binary memory dump of the NAND flash can be 
extracted. 

5. Analyze the extracted data using the forensic techniques and tools learned in this 
book. A raw . bin file will be obtained during the acquisition and most forensic 
tools support ingestion and analysis of this image format. 

It is also important to understand that the JTAG technique should not result in loss of 
functionality of the device. If reassembled properly, the device should function without any 
problems. Although the JTAG technique is effective in extracting the data, only experienced 
and qualified personnel should attempt it. Any error in soldering the JTAG pads or 
applying a different voltage could damage the device entirely. 

Chip-off 

Chip-off, as the name suggests, is a technique where the NAND flash chips are removed 
from the device and examined to extract the information. Hence, this technique will work 
even when the device is passcode-protected and USB debugging is not enabled. Unlike the 
JTAG technique where the device functions normally after examination, the chip-off 
technique usually results in destruction of the device, that is, it is more difficult to reattach 
the NAND flash to the device after examination. The process of reattaching the NAND flash 
to the device is called re-balling and requires training and practice. 

Chip-off techniques usually involve the following forensic steps: 

1. All of the chips on the device must be researched to determine which chip 
contains user data. Once determined, the NAND flash is physically removed 
from the device. This can be done by applying heat to desolder the chip, as 
shown in the following image (published by www . binaryintel . com). This is a 
very delicate process and must be done with great care as it may result in 
damaging the NAND flash. 
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The chip-off technique 

2. The chip is then cleaned and repaired to make sure that the connectors are 
present and functioning. 

3. Using specialized hardware device adapters, the chip can now be read. This is 
done by inserting the chip into the hardware device, which supports the specific 
NAND flash chip. In this process, raw data is acquired from the chip resulting in 
a . bin file. 

4. The data acquired can now be analyzed using forensic techniques and the tools 
described earlier. 

The chip-off technique is most helpful when the device is damaged severely, locked, or 
otherwise inaccessible. However, the application of this technique requires not only 
expertise but also costly equipment and tools. There is always a risk of damaging the 
NAND flash while removing it and hence it is recommended to try out the logical 
techniques first to extract any data. 
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While root access is a must to perform any of the techniques discussed earlier, it must be 
noted here that at the time of writing this book, none of these techniques would work on 
devices which have Full Disk Encryption (FDE) enabled. As discussed in Chapter 7, 
Understanding Android, Google has mandated the use of FDE for most devices starting from 
Android 6.0. Although some techniques were demonstrated and published for decrypting 
full disk encryption, they are device specific and are not widely applicable. 


Summary 

Extracting data from an Android device is one of the crucial steps during the course of an 
investigation. Once the device is accessible, an examiner can extract the data using manual, 
logical, or physical data extraction techniques. Logical techniques extract the data by 
interacting with the device using tools such as ADB. Physical techniques on the other hand 
access a larger set of data, they are complex and require great deal of expertise to perform. 
Imaging a device produces a bit-by-bit image of the device which is later analyzed using 
tools. Imaging a device is one of the primary steps to ensure that the data on the device is 
not modified. 

In the next chapter, we will see how to extract relevant data such as call logs, text messages, 
browsing history, and so on from an image file. We will also cover data recovery techniques 
using which we can recover the data deleted from a device. 
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A key aspect in iOS device forensics is to examine and analyze the data acquired to 
interpret the evidence. Data on most iOS devices is encrypted, and it requires that the data 
partition is decrypted prior to an examination. In the previous chapters, you learned 
various techniques to acquire data from an iOS device. The raw disk image obtained during 
physical acquisition, the file system dump, or the logical or backup file contains hundreds 
of data files that are often decrypted by the forensic tools described in earlier chapters. Even 
when the data is parsed and decrypted by the forensic tool, manual analysis may be 
required to uncover additional artifacts or to simply validate your findings. This chapter 
will help you understand how data is stored on iOS devices, and it will walk you through 
the key artifacts that should be examined in each investigation to recover the most data 
possible. 

In this chapter, we will be covering the following topics: 

• How iOS devices store data 

• Key artifacts to examine in every investigation (databases and plists) 

• The best tools and methods to extract key evidence 

• How to recover deleted data from key database files 


Timestamps 

Before examining the data, it is important to understand the different timestamps that are 
used on iOS devices. Timestamps found on iOS devices are presented either in the UNIX 
timestamp or Mac absolute time format. The examiner must ensure that the tools properly 
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convert the timestamps for the files. Access to the raw SQLite files will allow the examiner 
to verify these timestamps manually. Further information on iOS timestamps can be found 

at http : / / www .zdziarski. com/blog/ wp-content/uploads/2013/ 05/ iOS-Forensic 
-Investigative-Methods .pdf. 


UNIX timestamps 

A UNIX timestamp is the number of seconds that offsets the UNIX epoch time, which starts 
on January 1, 1970. A UNIX timestamp can be converted easily using the date command on 
a Mac workstation or using an online UNIX epoch converter on a Windows workstation. 
The date command is as follows: 

$date -r 1455070351 

Tues Feb 9 21:12:31 EST 2016 


Mac absolute time 

iOS devices adopted the use of Mac absolute time with iOS 5 for most of the data. Mac 
absolute time is the number of seconds that offsets the Mac epoch time, which starts on 
January 1, 2001. The difference between the UNIX epoch time and the Mac time is exactly 
978,307,200 seconds. To convert the UNIX epoch time to Mac absolute time, add 978,307,200 
to it and calculate it as a UNIX timestamp. For example, the date command that can be 
used to covert Mac absolute time is as follows: 

$date -r 1455070351 

Tues Feb 9 21:12:31 EST 2016 

Online converters prove to be useful to convert both Mac epoch and UNIX timestamps for 
iOS devices, especially when using a Windows PC. In addition to this, commercial forensic 
tools and open source scripts often provide converted date/time stamps. 


SQLite databases 

SQLite is an open source, in-process library that implements a self-contained, zero 
configuration, and transactional SQL database engine. This is a complete database with 
multiple tables, triggers, and views that are contained in a single cross-platform file. As 
SQLite is portable, reliable, and small, it is a popular database format that appears in many 
mobile platforms. 
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Apple iOS devices, like other smartphones, make heavy use of SQLite databases for data 
storage. Many of the built-in applications, such as Phone, Messages, Mail, Calendar, and 
Notes, store data in SQLite databases. Apart from this, third-party applications installed on 
the device also leverage SQLite databases for data storage. 

SQLite databases are created with or without a file extension. They typically have the 
. sqlitedb or . db file extensions, but some databases are given other extensions as well. 
Data in SQLite files is broken up into tables that contain the actual data. To access the data 
stored in these files, a tool that can read them is needed. Most commercial forensic tools, 
such as Oxygen, SQLite Forensic Browser, and Physical Analyzer provide support for the 
examination of SQLite databases. If you don't own one of these tools, some good free tools 
are as follows: 

• SQLite Browser: This can be downloaded from https : //github . com/rp-/sql 
itebrowser. 

• SQLite command-line client: This can be downloaded from http : //www . sqlit 
e . org/. 

• SQLite Professional (https : / /www. sqlitepro . com/): This is a free graphical 
user interface (GUI) from Hankinsoft Development for Mac OS X users. You can 
download it from Apple's App Store. 

• SQLite Spy: This is a free GUI tool for Windows. You can download it from http 
: / / www . yunqa . de/ delphi/ doku . php /product s/ sqlit espy/ index. 

Mac OS X includes the SQLite command-line utility (sqlite3) by default. This command-line 
utility can easily access individual files and issue SQL queries against a database. In the 
following sections, we will use both the sqlite3 command-line utility and other SQLite 
tools and browsers to retrieve data from various SQLite databases. Before retrieving the 
data, the basic commands that you will need to learn are explained in the following 
sections. 


Connecting to a database 

Manual examination of iOS SQLite database files is possible with the use of free tools. The 
following is an example of how to examine a database using native Mac commands in the 
terminal. Make sure that your device image is mounted as read-only to prevent changes 
being made to the original evidence. To connect to a SQLite database from the command 
line, run the sqlite3 command in the terminal by entering your database file. This will 
give you a SQL prompt where you can issue SQL queries: 

$sqlite3 filename . sqlitedb 
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SQLite version 3.8.5 2014-08-15 22:37:57 
Enter ".help" for usage hints. sqlite> 

To disconnect, use the . exit command. It exits the SQLite client and returns to the terminal 
prompt. 


SQLite special commands 

Once you connect to a database, there are a number of built-in SQLite commands, which are 
known as dot commands and can be used to obtain information from the database files. 

You can obtain the list of special commands by issuing the . help command in the SQLite 
prompt. These are SQLite-specific commands, and they do not require a semicolon at the 
end of the command. The most commonly used dot commands include the following: 

• . tables: This lists all of the tables within a database. The following example 
displays the list of tables found inside the sms . db database: 

sqlite> .tables 

_SqliteDatabaseProperties chat_message_join 
attachment handle 

chat message chat_handle_join 

message_attachment_join 

• . schema table-name: This displays the SQL CREATE statement that was used to 
construct the table. The following example displays the schema for the handle 
table, which is found inside the sms . db database: 

sqlite> . schema handle 

CREATE TABLE handle ( ROWID INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE, id 
TEXT NOT NULL, country TEXT, service TEXT NOT NULL, uncanonicalized_id 
TEXT, UNIQUE (id, service) ); 

• .dump table-name: This dumps the entire content of a table into SQL 
statements. The following example displays the dump of the handle table, which 
is found inside the sms . db database: 

sqlite> . dump handle 
PRAGMA foreign_keys=OFF; 

BEGIN TRANSACTION; 

CREATE TABLE handle ( ROWID INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE, id 
TEXT NOT NULL, country TEXT, service TEXT NOT NULL, uncanonicalized_id 
TEXT, UNIQUE (id, service) ); 

INSERT INTO "handle" 

VALUES (7, ' 9951512182 ' , ' in ' , 'SMS ' , ' 9908923323 ' ) ; 
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COMMIT ; 

• . output file-name: This redirects the output to a file on the disk instead of 
showing it on the screen. 

• . headers on: This displays the column title whenever you issue a SELECT 
statement. 

• . help: This displays the list of available SQLite dot commands. 

• . exit: This disconnects from the database and exits the SQLite command shell. 

• . mode MODE: This sets the output mode where MODE can be csv, HTML, tabs, and 
so on. 



Make sure that there is no space in between the SQLite prompt and the dot 
command; otherwise, the entire command will be ignored. 


Standard SQL queries 

In addition to the SQLite dot commands, standard SQL queries, such as 
SELECT, INSERT, ALTER, DELETE, and more, can be issued to SQLite databases on the 
command line. Unlike the SQLite dot commands, standard SQL queries expect a semicolon 
at the end of the command. 

Most of the databases that you will examine will contain only a reasonable number of 
records, so you can issue a SELECT statement, which outputs all of the data contained in the 
table. This will be covered in detail throughout this chapter. 


Accessing a database using commercial tools 

While manual examination of iOS SQLite database files is possible with the use of free tools, 
most examiners prefer commercial support prior to digging manually in the files for 
examination. The following is an example of how to examine a database using SQLite 
Forensic Browser— a Windows based tool by Sanderson Forensics at http : //www . sanders 
onforensics . com/forum/ content . php. 
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Launch SQLite Forensics Browser and navigate to File I Create New Case or File I Open 
SQLite DB: 


File View Export Report Queries Search Tools Extensions About 
Visual 

Main 



B Main 

FIELDS” 
1 FROM 



Creating a case in SQLite Forensics 

Once the SQLite DB file is open, the examiner can access the various tables that are 
contained within the database, leverage the tool to convert date/time stamps, and visually 
look at the SQL queries being run behind the scenes to access the data. The sms . db file is 
being loaded into the tool for examination in the following screenshot: 
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Loading a database into SQLite Forensics 

Once loaded, tables can be selected for parsing. Note that the tool displays the queries that 
are being run behind the scenes to produce the output. These queries should be the same 
ones that will be displayed manually later in this chapter. These queries can be used on a 
Mac to validate your findings: 
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♦ Forensic Browser for SQlite v2.7.3b (c) Sanderson Forensics Ltd. 201S • Licenced : ONLY for use by : Heather Mahalik 

Export Report Queries Search Tools Extensions About 


File View 

Visual query 


B Mam 
B FIELDS 

message, guid 
message, "text" 
message, date 
message . date_read 
message . date_delvered 
message . s_from_me 
B FROM 

message 


SQL 

SELECT message.guid. 




country Text 
attnbutedBody Blob 
version Integer 
type Integer 


lOutputlExpression 

Aqqreqate 


Alas 

Sort Type |Sort Order 

Groupnq 

Cntera 

Of... 

O' 

rnessaqe.quid 










* message, "text" 










* message.date 










w ’ message.date read 










v* mpwnp rtatp Hp4v 













message, "text", 
message.date, 
message.date_read, 
message.date_delvered , 
message.s_from_me 
FROM message 


Results, ROWS = 14,291 



guld 

text 

date 

date_read 

date_dekvered 

from me 


9A37F048-F23B-4507-818B-CA928261CC99 

Are u bunging )adc? 

409184309 

0 

409194395 

1 

s> 

AF866A08-6314-4161-98AA-29C70C265E0A 

Good morning ■ 

409325383 409325421 

Ol 

0 


AA2EAAE9-3E63-4867-B83F-180A8F0652CC 

Good momng. He just woke up at 8:10 and 6 eating 

409325444 

0 

409325448 

1 


E775E7F2-AEBD-46FF-BD00-FCD8259A32EE 

He s a very good boy. 

409325484 

409325484 

o 

0 


2B03C002-99C8-48S3-8EA9-1E0A99B9DCC4 

■P 

409325498 

0 

409325500 

1 


02E512FC-9FB0-4EED-8F6C23FBBS3D1ECC 

Good, it is beautful. I have seen a few doe and one young buck 

409325568 

409325573 

ol 

0 


64888AC6 2 1 E7-4B51 -AAC6-6FE49267785C 

Ok. Be careful Come home soon □ 

409325620 

0 

409325627 

1 


E71AE534-81DC-4AA3-BE9C-8E28E6FF352S 

HI 

409325660 

409325677 

of 

0 


8851F9A5-64DO-44D7-8C4D-B4DD5DO09A1 1 

We bve u 

409325689 

0 

409325691 

1 


81 E92BD9-145C-4F9F-9957-538F902D51 14 

c 

409325696 

409325801 

0 

0 


9DA469D5-5 1 64-4A32-A580-7F5661041C5B 

Rich? 

409325807 

0 

409325809 

1 


8B49D224-6C46-446A-A6F1 -0F3C208BDF6D 

Not sure, we shall see 

409325824 

409325854 

°I 

0 


8D3A0E3E-O9F5-4C0F-AO55-65359D3E30DC 

SicDad, let's go to navy fed before It rams' 

409328137 

0 

409328147 

1 


8BB29AFE-E8F9-4FFC-AD58-F 1 22B1 D88CB4 

Be home soon son. 

409331840 409332739 

0 

0 







Examining the SHIS . cLb file in SQLite Forensics 

All of the columns can be formatted to show the best version of the data. For example, the 
date/time stamps highlighted in the preceding screenshot can be converted to Mac Absolute 
Time within the tool, as discussed earlier in this chapter. Simply right-click on it and select 
the date format: 
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Data conversion selection in SQLite Forensics 

Once converted, the dates and time shown previously are converted to a format that is 
easier to examine: 
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date 

date_read 

date_deivered 

is_from_me 

2013/12/19 22:18:29 


2013/12/19 20:06:35 

1 

2013/12/21 13:29:43 

2013/12/21 13:30:21 


0 

2013/12/21 13:30:44 


2013/12/21 08:30:48 

1 

2013/12/21 13:31:24 

2013/12/21 13:31:24 


0 

2013/12/21 13:31:38 


2013/12/21 08:31:40 

1 

2013/12/21 13:32:48 

2013/12/21 13:32:53 


0 

2013/12/21 13:33:40 


2013/12/21 08:33:47 

1 

2013/12/21 13:34:20 

2013/12/21 13:34:37 


0 

2013/12/21 13:34:49 


2013/12/21 08:34:51 

1 

2013/12/21 13:34:56 

2013/12/21 13:36:41 


0 

2013/12/21 13:36:47 


2013/12/21 08:36:49 

1 

2013/12/21 13:37:04 

2013/12/21 13:37:34 


0 

2013/12/21 14:15:37 


2013/12/21 09:15:47 

1 

2013/12/21 15:17:20 

2013/12/21 15:32:19 


0 


Data conversion output in SQLite Forensics 

All of the database files that are described next can be loaded, examined, and reported 
using a tool such as SQLite Forensics Browser. In addition to this, the database files 
explained in the following sections can be exported from SQLite Forensics Browser by 
creating a report or exporting relevant files to include in your final forensic report. 


Key artifacts - important iOS database files 

Raw disk images, file system and logical dumps, and the backup that you extracted as per 
the instructions in Chapter 4, Data Acquisition from iOS Devices, and Chapter 5, Data 
Acquisition from iOS Backups, should contain the following SQLite databases that may be 
important to your investigation. Should these files not be recovered, make sure that you 
acquired the iOS device correctly. The files that are shown in the following sections are 
extracted from an iOS 9 device. As Apple adds new features to the built-in applications 
with every iOS release, the format of the files may vary for different iOS versions. The 
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locations of these files have also changed since iOS 6, so make sure to learn where your key 
artifacts are located. Due to version changes, you may need to modify the queries listed 
slightly to work on your iOS version. More information regarding important database files 
can be found at https : / /digital-forensics . sans . org/ media/ for 5 8 5-poster . pdf. 


Address book contacts 

The address book contains a wealth of information about the owner's personal contacts. 
With the exception of third-party applications, the address book contains contact entries for 
all of the contacts that are stored on the device. The address book database is a HomeDomain 
file, and it can be found 

at private/var/mobile/Library/AddressBook/AddressBook . sqlitedb. The 

AddressBook . sqlitedb file contains several tables, of which the following three are of 
particular interest: 

• ABPerson: This contains the name, organization, notes, and more for each 
contact. 

• ABMultiValue: This contains phone numbers, e-mail addresses, website URLs, 
and more for the entries in the ABPerson table. The ABMultiValue table uses 
a record_id file to associate the contact information with a rowid from 

the ABPerson table. 

• ABMultiValueLabel: This table contains labels to identify the kind of 
information stored in the ABMultiValue table. 

Some of the data stored within the AddressBook . sqlitedb file could be from third-party 
applications. The examiner should manually examine the application file folders to ensure 
that all the contacts are accounted for and examined. 

While all commands below can be run natively on a Mac, we are going to use SQLPro for 
SQLite to examine the most common databases found on iOS devices and add some 
commercial tools, where relevant, to show a variety of examination options. This is a free 
tool that simplifies the process and provides a clear view of the data to the examiner. Once 
the database is loaded, you can draft queries to examine the data most relevant to you and 
the address book into a CSV file named AddressBook . csv: 
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• • • 


(Tj AddressBook.sqlitedb 

ill Q <7> 


ABGroup 

0 row* 

ABGroupChanges 

0 row* 

ABGroupMembers 

0 row* 

ABMuftiValue 

QUO row* 

ABMuttlValueEntry 

M rows 

ABMultiValueEntryKey 

10 row* 

ABMultiValueLabel 

14 row* 

ABPerson 

694 row* 

ABPersonBasicChanges 

10 row* 

ABPersonChanges 

ABPersonFullTextSearch 

ABPersonFullTextSearch.conter 

004 row* 

ABPerson FullTextSearch_docsiz 


SELECT 
ROWID, 

First, 

Middle, 

Last, 

datetimeCcreationDate ♦ 978307200, 'tHIXEPOCH' ) AS M Creation_date*', 

organization, 

note. 

Birthday, 

Nickname, 

JobTitle, 

datetime(iMdificationOate ♦ 978307200, •UNIXEPOOf ) AS M Hodif icat ion.date" 
FROM ABPerson 
ORDER by ROWID ASC; 


Export 


Favorites Q History |Qj 


V 


a ■ 




[ ABPersonFullTextSearch_segdlr 


+ * 


Upgrade 


Note ^ 


Birthday 

Nickname 

JobTitle 

Modification.date 


▼ 11/25/2015 This contact was added from Micr.. 

▼ 

NULL 

NULL 

NULL 

2015-11-30 20:10:30 ▼ 

NULL 


NULL 

NULL 

NULL 

2015-11-30 20:10:29 * 

1 1/25/2015 This contact was added from Micr.. 

▼ 

NULL 

NULL 

NULL 

2015-11-30 20:10:30 ▼ 

11/25/2015 This contact was added from Micr 

▼ 

NULL 

NULL 

NULL 

2015-11-30 20:10:29 ▼ 

1 1/25/2015 This contact was added from Micr.. 

▼ 

NULL 

NULL 

NULL 

2015-11-30 20:10:29 * 

NULL 


NULL 

NULL 

NULL 

2015-11-30 20:10:30 ▼ 

1 1/25/2015 This contact was added from Micr.. 

▼ 

NULL 

NULL 

NULL 

2015-11-30 20:10:30 ▼ 

NULL 


NULL 

NULL 

NULL 

2015-12-16 14:22:52 * 

NULL 


NULL 

NULL 

NULL 

2015-12-16 14:22:52 ▼ 

NULL 


NULL 

NULL 

NULL 

2015-12-16 14:22:52 * 

NULL 


NULL 

NULL 

NULL 

2015-12-16 14:22:52 ▼ 

NULL 


NULL 

NULL 

NULL 

2015-12-16 14:22:52 ▼ 

▼ NULL 


NULL 

NULL 

NULL 

2015-12-20 16:01:15 ▼ 

694 records. 0.5 seconds. 



Export Q 


The AddressBook . sqlitedb file inSQLPro 

Above, you can see the suggested query to parse data from the ABPerson table. In later 
examples, table joins may be required to capture all of the information. The query also 
converts the Mac absolute time into a readable form using the SQLite datetime function. 
The results can be exported for insertion in your final forensic report. 
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ROWID 

First 

Middle 

Last 

Creation date 

Organization 

Note 


Nickname 

Modification date 

2 

Dad 

<null> 

<null> 

2012-06-24 22:58:14 

<null> 

cHTCDatax 

Favoriteictiomd 

<null> 

2015-09-16 23:32:56 

3 

Andy 

<null> 

<null> 

2012-06-24 22:58:14 

SANS Singapore 

<null> 


<null> 

2015-09-16 23:32:56 

4 

Heather 

<null> 

Mahalik 

2012-06-24 22:58:14 

<null> 

<null> 

Hank 

2015-09-16 23:32:56 

5 

Lee 

<null> 

<null> 

2012-06-24 22:58:14 

<null> 

<null> 

<null> 

2015-09-16 23:32:56 

6 

Hayes 

<null> 

<null> 

2012-06-24 22:58:14 

<null> 

<nulb> 

<null> 

2015-09-16 23:32:56 

7 

Tabs 

<null> 

<null> 

2012-06-24 22:58:14 

<null> 

<null> 


<null> 

2015-09-16 23:32:56 

8 

Jus 

<null> 

<null> 

2012-06-24 22:58:12 

<null> 

<HTCData>J 

Favoriteaactionid 

<null> 

2015-09-16 23:32:56 

9 

Suresh 

<null> 

<null> 

2012-06-24 22:58:14 

<null> 

<null> 

1 1 

<null> 

2015-09-16 23:32:56 

10 

New 

<null> 

<null> 

2012-06-24 22:58:14 

<null> 

<nulb> 

<null> 

2015-09-16 23:32:56 

11 

Crogs 

<null> 

<null> 

2012-06-24 22:58:14 

<null> 

<HTCData>«^^^^^Jictionid 

<null> 

2015-09-16 23:32:56 

13 

Rach 

<null> 

<null> 

2012-06-25 15:55:31 

<null> 

<null> 

<null> 

2015-09-16 23:32:56 

14 

Hardcopy 

<null> 

<null> 

2012-06-25 15:55:31 

<null> 

<null> 

<null> 

2015-09-16 23:32:56 


SQLPro output from the AddressBook . sqlitedbfiie 

Note that "favorites" are called out in the Notes section. Thus, when a user marks a contact 
as a favorite, you may find this artifact. It is common for some columns to contain little to 
no data. 

Address book images 

In addition to the address book's data, each contact may contain an image associated with 
it. This image is displayed on the screen whenever the user receives an incoming call from a 
particular contact. These images can be created by third-party applications that have access 
to the contacts on the device. Often, the contact is linked to a third-party application profile 
photo. The address book images database is a HomeDomain file, and it can be found 
at /private/var/mobile/Library/AddressBook/AddressBooklmages . sqlitedb. 

The address book images can be parsed manually, but using commercial software makes 
this process much more practical. Most free and commercial tools will provide access to the 
address book images. However, some tools will not make the link between the graphic and 
the contact, which may require some manual rebuilding. Sometimes, the free solutions 
work best when parsing simple data from iOS devices. Next, we examine the address book 
images in iExplorer, which was introduced in Chapter 5, Data Acquisition from iOS 
Backups. In this example, we simply loaded the iOS dataset into iExplorer and navigated to 
the AddressBooklmages . sqlitedb file for examination. 
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Examining AddressBooklmages . sqlitedb iniExpiorer 


In this example, we can see that Kathryn is a contact on the phone, and her profile picture is 
being pulled from her Google account. Thus, the iPhone user in this example provided 
Google access to the contacts and the link was made. This happens often with common 
applications, such as Twitter, Facebook, Google, Linkedln, and Instagram, to name a few. 

When the user links a picture from their phone or takes a picture using the camera and 
assigns the photo as a contact, you will find no reference to a profile for the photo and the 
output will resemble what is shown in the following screenshot for the contact: 
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Call history 

Phone or FaceTime calls placed, missed, and received by the user are logged in the call 
history along with other metadata, such as call duration, date/time, and more. The call 
history database is a WirelessDomain file, and it can be found at 
/ private/var/ wireless /Library/ CallHi story/ cal l_hi story . db or 
/private/var/wireless/Library/CallHistory . storedata, depending on the iOS 
version. The CallHistory . storedata file was introduced with iOS 8 and is currently in 
use at the time of writing (iOS 9). Keep in mind that most devices can be updated and will 
most likely have data in both locations, which means that you need to be aware of how the 
data is stored in each location and whether or not your tool is extracting data from each 
database. For this reason, we will examine both in this section. 

The Call table in the call_history . db or CallHistory. storedata file contains the call 
history. Depending on the database that is used, a limited number of calls may be stored in 
the active database. Just because the database removes the oldest record when space is 
needed does not mean this data is deleted. It's simply in the free pages of the SQLite 
database file, and it can be recovered using forensic tools or manually. Each record in 
the call table indicates the phone number or address, a UNIX timestamp of when the call 
was initiated, the duration of the call in seconds, a status flag to identify whether the call 
was an outgoing call, incoming call, blocked call, or FaceTime call, the mobile county code 
(MCC), the mobile network code (MNC), and more. You can find a list of MCC/MNC codes 
at http ://en. Wikipedia . org/ wiki/Mobile_country_code. 

The status flags for calls have changed as iOS versions are modified. In order to avoid 
confusion, we encourage you to recreate a call log if the status flags do not seem to make 
sense. The best way to understand the evidence is often to recreate it yourself. Simply place, 
accept, and reject a call, conduct the same with FaceTime, and examine your findings. Just 
make sure that you are using the same iOS version of the device that you are examining. 

FaceTime status flags may vary depending on the method that is used to initiate the call. 

For example, data plans utilize different flags than Wi-Fi calls. When considering the 
importance of this, think about if Wi-Fi was used. We could then dig deeper and examine 
Wi-Fi access points that the device was connected to and place the device at a specific 
location when a call was made. There are several status flags that are available for FaceTime 
calls, and these vary between iOS devices, so again, please validate your findings. 

You can run the following queries in SQLPro for SQLite to dump the call history into a CSV 
file named callhistory_storedata . csv: 
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| ZCALLDBPROPERTIES 
ZCALLRECORD 


Z_PK 

11 Z_ENT 

LI Z-OPT 

p| ZANSWERED 

PI ZCALLTYPE 

Kl ZDISCONNECTED.CAUSE 

II ZFACE_TIME_DATA 

II ZNUMBER_AVAILABILITY 

p| ZORIGINATED 

B| ZREAD 

|l| ZDATE 

PI Z DU RATI ON 

PI ZDEVICEJD 

p| ZISO_COUNTRY_CODE 

II ZLOCATION 

III ZNAME 

PI ZUNIQUEJD 
II ZADDRESS 


SELECT 

ZCALLTYPE AS "1-normal, 8=Facetime" , 

datetimeCZDATE+978307200, 'UNIXEPOCH' , 'localtime') AS "Date" , 
ZDURATION AS "Duration in seconds", 

ZLOCATION AS "location of device phone number", 

ZADDRESS —ASCII 
FROM ZCALLRECORD 


Favorites v History v 


V 


ss © 



|l=normal, 8= Facetime I Date 

Duration in seconds 

location of device phone number 


3 



NULL 

UXdt 

4 

1 2015-11-29 00:37:57 

150 

Falls Church, VA 

0x31 

6 

1 2015-11-29 01:34:01 

22 

Falls Church, VA 

0x31 

6 

1 2015-11-29 01:48:41 

548 

NULL 

0x31 

7 

1 2015-11-29 02:37:56 

270 

Paxtang, PA 

0x21 

8 

1 2015-11-29 17:44:13 

3 

West Whiteland, PA 

0x31 

9 

1 2015-11-29 18:56:00 

47 

Paxtang, PA 

0x31 

10 

1 2015-11-30 02:43:17 

26 

Langhorne, PA 

0x3: 


1 2015-11-30 02:44:59 

938 

Langhorne, PA 

0x3: 

12 

1 2015-11-30 15:33:30 

33 

Annapolis, MD 

0x21 

13 

1 2015-11-30 15:34:28 

340 

Annapolis, MD 

0x3' 

14 

1 2015-11-30 15:54:34 

10 

Philadelphia, PA 

0x21 

15 

1 2015-11-30 15:54:56 

44 

Philadelphia, PA 

0x21 

16 

1 2015-11-30 16:50:55 

88 

Langhorne, PA 

0x3: 

17 

1 2015-11-30 16:56:29 

862 

Langhorne, PA 

0x31 

16 

1 2015-11-3019:01:38 

89 

Norristown, PA 

0x2a 

19 

1 2015-11-30 19:54:34 

250 

Falls Church, VA 

0x39 

20 

1 2015-11-30 20:45:32 

81 

West Chester, PA 

0x2l| 



Finished with 552 records. 0.24 seconds. 
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Examining CallHistory . Storedata in SQLitePro 

In the preceding screenshot, we can see the SQL queries that are required to parse 
CallHistory . storedata from an iOS 9 device. In this particular database, normal calls 
were identified with the flag of 1 and FaceTime as 8. With this version of iOS, the call log 
also attempts to associate a phone number with a location. This data should be verified 
prior to including it in your report. 

Commercial tools can also be used to parse this information. Each tool will function 
differently, and it will provide access to various amounts of extracted data. Again, it is the 
job of the examiner to determine whether all data was extracted, is it being interpreted by 
the tool correctly (that is, status flags, dates, and more), and do you need to manually query 
the data for verification, as shown in the preceding screenshot. The results are shown in 
BlackLight in the following screenshot (refer to https : //www.blackbagtech . com/softw 
are-products/blacklight-6 . html): 
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Examining CallHistory . Storedata in BlackLight 

If you are examining a device that has been upgraded, you need a tool that will parse both 
or a tool that provides access to the raw databases for you to examine by running the 
previous queries. In the following example, we examine an iPhone 5s that was released 
with iOS 7 but was upgraded to iOS 9. UFED Physical Analyzer is being used to examine 
these call logs. We see that 792 calls are being extracted by the tool. In this example, the tool 
was parsing both the call_history . db and CallHistory . storedata files in addition to 
parsing deleted data. As shown in the following screenshot, we not only see the extracted 
information (address, linked name from contacts, timestamp, duration, type, and source), 
but we also get access to the location in Hex for where this data is being extracted. This 
makes verification a lot easier. 
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Examining CallHistory. storedata and Cal l_hi story . db files in Physical Analyzer 


As you may need to query call_history . db to extract information if you don't have 
access to commercial tools, the following screenshot shows you how to do this. In this 
example of an iPhone 5s running iOS 7, the following status flags were validated: 17 = 
outgoing FaceTime, 16 = incoming or missed FaceTime, 9 = outgoing call, and = incoming 
call. Again, it is best to validate your findings every time you examine a new iOS version. 


[ 194 ] 




iOS Data Analysis and Recovery 



Examining call_hi Story . db in SQLitePro 


SMS messages 

The Short Message Service (SMS) database contains text and multimedia messages that 
were sent from and received by the device along with the phone number of the remote 
party, date and time, and other carrier information. Starting with iOS 5, iMessages data is 
also stored in the SMS database. iMessage allows users to send SMS and MMS messages 
over a cellular or Wi-Fi network to other iOS or OS X users, thus providing an alternative to 
SMS. The SMS database is a HomeDomain file, and it can be found 

at /pr i vat e/var /mobile /Library /SMS /sms . db. This location has not changed as iOS 
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versions have been released. 

You can run the following queries in SQLitePro for SQLite and dump the SMS database into 
a CSV file named sms . csv: 



Examining SHIS . clb in SQLitePro 


Calendar events 

Calendar events that have been manually created by the user or synced using a mail 
application or other third-party applications are stored in the calendar database. The 
calendar database is a HomeDomain file and can be found 

at / pr i vat e/var /mobile /Library/ Calendar/ Calendar . sqlitedb. 

The Calendarltem table in the Calendar . sqlitedb file contains the calendar events 
summary, description, start date, end date, and more. You can run the following queries in 
SQLite Pro for SQLite to dump the calendar database into a CSV file named calendar . csv: 
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Examining calendar . sqlitedb in SQLitePro 

Note that reminders and tasks are often saved in the Calendar . sqlitedb file. These files 
may not contain a start or end time depending on the event. In addition to this, the 
preceding description column will include details that were included in the calendar invite, 
as shown in the preceding screenshot. In addition to this, calendar items can contain 
completion dates (to-do or task items), reminder dates/times, and exist from multiple 
locations (that is, e-mail accounts, third-party applications, and more). It is best to use a 
commercial tool when possible so that these items are easy to parse. From here, dive deep 
into the manual queries to validate your tool. When multiple items are feeding information 
into the Calendar, the Calendar and Calendarltem tables will have to be joined in the 
query. An example of multiple feeds into one Calendar is shown in UFED Physical 
Analyzer, as follows: 
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Notes 

The Notes database contains the notes that are created by the user using the device's built- 
in Notes application. Notes is the simplest application, often containing the most sensitive 
and confidential information. The Notes database is a HomeDomain file and can be found 

at /private /var /mobile /Library /Notes /notes . sqlite. 

The Znote and Znotebody tables in the notes . sqlite file contain the notes title, content, 
creation date, modification date, and more. You can run the following queries to dump 
the Notes database into a CSV file named notes . csv: 
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Examining notes in SQLitePro 


Safari bookmarks and cache 

The Safari browser used on an Apple device allows users to bookmark their favorite 
websites. The bookmarks database is a HomeDomain file, and it can be found 
at /private/var/mobile/Library/ Safari/Bookmarks . db. The Safari browser stores 
the recently downloaded and cached data in a database. The database is a HomeDomain file 
and can be found 

at /private/var/mobile/Library/ Caches/ com. apple .mobilesafari/ Cache . db. 

The file contains cached URLs and the web server's responses along with the timestamps. In 
addition to this. Safari stores information from various sites in the WebKit database that is 
located in the /private/var/mobile/Library/WebKit/LocalStorage/ directory. The 
directory contains unique databases for each website, as shown in the following screenshot: 
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mbp-hmahalik:Webkit hmahalik$ cd /Users/ 
hmaha l ik/Desktop/Webkit /Localstorage 
mbp-hmahalik: LocalStorage hmahalikS Is 
StorageT racker. db 

http_wwv/. google. com_0. locals to rage 
http_m. youtube. com_0. localstorage 
http_wv*w. youtube. com_0. localstorage 
http_www. bing. com_0. localstorage 
https_m. facebook. com_0. localstorage 
mbp-hmahalik: Localstorage hmahalikS 


The Localstorage folder contents 


All of the Safari files can be extracted using queries, as already demonstrated. In addition to 
Safari, other browsers can be used and contain data on an iOS device. For this reason, we 
recommend using a tool built to parse Internet History to ensure that data is not 
overlooked. Magnet Forensics offers IEF Mobile (Internet Evidence Finder), which is 
fantastic for the extraction of browser artifacts from iOS devices. 


The photos metadata 

A manifestation of the photos in the device's photo album is stored in a database located at 

/private/var/mobile/Media/PhotoData/Photos . sqlite. The photos metadata 
database file is a member of CameraRollDomain. 

You can run the following queries to view the photos stored in the database. From here, you 
can use the directory to locate the file path and the filename to track down the photo: 
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Examining photos . Sqlite in SQLitePro 


Consolidated GPS cache 

Geolocation history of cell towers and Wi-Fi on the device is stored in one of the two 
possible databases that are located at /private/var/root/Caches/locationd/. The 
databases are either consolidated, db or cache_encryptedA. db. Both database files are 
members of RootDomain. The version of iOS will determine which database is used. These 
databases contain location information for cell towers that the device came into close 
proximity with, as well as Wi-Fi networks that were available for the device to connect to. 
These databases are often used to place a person near a specific location, as this data is 
cached to one of these database files without the user's consent. 

For this example, we will examine the consolidated, db file. The CompassCalibration 
table in the consolidated . db file contains the location information along with the 
timestamps. The file, when opened with SQLite Professional, displays the data, as shown in 
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the following screenshot. Note that the cache_encryptedA. db file is no longer backed up 
when the user syncs with iTunes. In addition to this, location information exists all over the 
iOS device. Tying a location to the device is one of the more complex topics and takes some 
time to master: 



The Consolidated . db view with SQLitePro 


Voicemail 

The voicemail database contains metadata about each voicemail that is stored on the 
device that includes the sender's phone number, callback number, timestamp and message 
duration, and more. The voicemail recordings are stored as AMR audio files that can be 
played by any media player that supports the AMR codec (for example, QuickTime 
Player). The voicemail database is a HomeDomain file, and it can be found at 
/private/var/mobile/Library/Voicemail/voicemail . db, while the actual voicemail 
recordings are stored in the /private/var/mobile/Library/Voicemail/ directory. 
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Property lists 

A property list, commonly referred to as a plist, is a structured data format used to store, 
organize, and access various data types of data on an iOS device as well as a Mac OS X 
device. Plists are binary-formatted files, and they can be viewed using a Property List 
Editor, which is capable of reading or converting the binary format to ASCII. 

Plist files may or may not have a .plist file extension. To access the data stored in these 
files, you need a tool that can read them. Some of the good free tools include the following: 

• Plist Editor for Windows, which can be downloaded from http : / / www . icopybo 
t . com/plist-editor . htm 

• The plutil command-line utility on Mac OS X 

You can also view the plist files using XCode. Mac OS X includes the plutil command-line 
utility by default. The command-line utility can easily convert the binary-formatted files 
into human readable files. In addition to this, most commercial forensic tools, such as 
Oxygen Forensics, include great support to parse plist files. 

The following example displays the Safari browser com . Apple . maps .plist file: 


; y w x 

XML View List View 

Key 

Type 

Value 


MNMainCameraZoomScale 

real 

0J333333333333333 

■* 

MainScreenlastViewportCbangeDatdate 

2015-12-22T1712;49 


MapsAdivity 

data 



MaptRAPOvicelO 

tiring 

87FCD3FF-8B4S-4CA 


MapsT raffitWaiSctToDcfauH 

boolean 

true 


MigratedToMapsActivityProto 

boolean 

true 


Preferred! ransport 

string 

Prefer Driving 


RecentsNoResultC acheldsKey 

array 



RouteEndStnnqbAtom 

boolean 

false 


RouteStartSulnglsAtom 

boolean 

true 


* SSDeviceType 

did 



SSDeviceType. N51AP 

integer 

89 


SSDevirelype N94AP 

integer 

73 


Sr* ft hRiirt ompIrhonModr 

integer 

2 


SearthlnfoRuaionChangcTimestamprcdl 

432499861.32046402 


SearchMode 

integer 

1 


SearchRequestWithoutPromptCountlinteger 

60 


SearrhString 

string 

177S Wienie Ave. Un 


Spare hStrinqhAtom 

boolean 

false 


SyiKMdr>jger.bockrmirkv.syTKcd 

boolean 

true 

- 

pint Editor Pro V 2.1 






The C om . App 1 e . map S . P 1 i S t in Plist Editor for Windows 
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Important plist files 

Raw disk images or the backup that you extracted in Chapter 4, Data Acquisition from iOS 
Devices, and Chapter 5, Data Acquisition from iOS Backups, should contain the following 
plist files that are important for an investigation. The files displayed are extracted from an 
iOS 9 device. The file locations may vary for your iOS version. 

The HomeDomain plist files 

The following are the HomeDomain plist files, which contain data that may be relevant to 
your investigation: 

• / private/var /mobile /Library /Preferences/ com . apple . mobilephone . p 

list: This contains the last phone number entered into the dialer regardless of 
whether it was dialed or not 

• /private/var/mobile/Library/Preferences/ com. apple .mobilephone . s 
peeddial . plist: This contains a list of the contacts that were added to the 
phone's favorite list 

• /private/var/mobile/Library/Preferences/ com. apple . accountsettin 

gs . plist: This contains a list of the e-mail accounts configured on the device 

• / private/var /mobile /Library /Preferences/ com . apple . AppSupport . pi 
ist: This contains the country code that was used for the App Store on the device 

• /private/var /mobile /Library /Preferences /com. apple .Maps .plist: 
This contains the last latitude, longitude, and address pinned in the Maps 
application 

• / private/var /mobile /Library /Preferences/ com . apple . mobilemail . pi 

ist: This contains the e-mail fetching dates and the e-mail signatures used 

• / private/var /mobile /Library /Preferences/ com . apple . mobiletimer . p 
list: This contains a list of world clocks used 

• /private/var /mobile /Library /Preferences /com . apple . Preferences . p 
list: This contains the keyboard language that was last used on the device 

• /private/var /mobile /Library /Preferences /com. apple . mobilesaf ari . 
plist: This contains a list of the recent searches made through Safari 

• / private/var /mobile /Library /Preferences/ com . apple . springboard . p 
list:This contains a list of applications that are shown in the interface and iOS 
version 

• / private/var /mobile /Library /Preferences/ com . apple . mobiletimer . p 

list: This contains information about the current time zone, timers, alarms, and 
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stopwatches 

• /private/var /mobile /Library /Preferences /com . apple . weather . plist 

: This contains the cities for weather reports, date, and time of the last update 

• /private/var /mobile /Library /Preferences /com. apple .stocks. plist: 

This contains a list of the stocks tracked 

• /private/var/mobile/Library/Preferences/ com. apple .preferences . n 
etwork . plist: This contains the status of Bluetooth and Wi-Fi networks 

• /private/var/mobile/Library/Preferences/com. apple . conference . hi 
story . plist: This contains a history of the phone numbers and other accounts 
that were conferenced using FaceTime 

• /private/var /mobile /Library /Preferences /com. apple .locationd.pli 

st: This contains a list of application identifiers that use the location service on 
the device 

• /private/var/mobile/Library/ Safari/History .plist: This contains the 
web browsing history of Safari 

• / private/var/mobile/Library/ Safari/ SuspendState .plist: This 
contains the web page title and the URL of all suspended web pages on Safari 

• /private/var /mobile /Library /Maps /Bookmarks .plist: This contains the 
bookmarked locations within the Maps application 

• /private/var/mobile/Library/ Caches/ com . apple . mobile .install at io 
n . plist: This contains a list of all system and user applications loaded onto the 
device and their disk paths 

• /private/var/mobile/Library/ Caches/ com . apple . UIKit . pboard/ paste 
board: This contains a cached copy of the data stored on the device's clipboard 


The RootDomain plist files 

The following RootDomain files listed should be examined for relevance to your 
investigation: 

• /private/var /root /Library /Preferences /com . apple . preferences . net 
work .plist: This contains information about whether airplane mode is 
presently enabled on the device 

• /private/var/root/Library/Lockdown/pair_records: This directory 
contains property lists with private keys used in order to pair the device to a 
computer 

• /private/var/root/Library/Caches/locationd/clients .plist: This 
contains the location settings for applications and system services 
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The WirelessDomain plist files 

The following WirelessDomain plist file contains useful information to identify the SIM 
card last used in the device and other information: 

/private/ wireless /Library /Preferences/ com. apple . commcenter .plist 


The SystemPreferencesDomain plist files 

The two plist files containing data of evidentiary value from the 
SystemPreferencesDomain files are listed, as follows: 

• / private/var /preferences/ SystemCon figuration/ com . apple . network . 
identification .plist: This contains networking information of the cached IP 

• /private/var/preferences/ SystemConf iguration/ com. apple .wifi .pli 
st: This contains a list of previously known Wi-Fi networks and the last time 
each one was connected to 


Other important files 

Apart from SQLite and plist files, several other locations may contain valuable information 
to an investigation. 

The others sources include the following: 

• Cookies 

• Keyboard cache 

• Photos 

• Wallpaper 

• Snapshots 

• Recordings 

• Third-party applications 
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Cookies 

Cookies can be recovered 

from /private/var/mobile/Library/Cookies/Cookies . binarycookies. This file is a 
standard binary file containing cookies that are saved when web pages are accessed on the 
device. This information can be a good indication of what websites the user has been 
actively visiting. Keep in mind that third-party applications may also contain this file. 

To convert the binary cookie to human readable format, run the BinaryCookieReader .py 
Python script on the cookie file, as in the following command (the Python script source code 
is available in the code bundle of the book): 

$python BinaryCookieReader . py Cookies . binarycookies 

Cookie : utma=l 67051323 . 813879307 . 1359034257 . 1367989551 . 1386632713 .9; 

domain=. test flightapp.com; path=/; expires=Wed, 09 Dec 2015; 

Cookie : utmb=167051323 . 24 . 8 . 1386633092975; domain= . testf lightapp . com; 

path=/; expires=Tue, 10 Dec 2013; 

Cookie : 

utmz=167051323 . 1386632713 .9.1. utmcsr= (direct) | utmccn= (direct) | utmcm 

d= (none) ; domain= . testf lightapp . com; path=/; expires=Tue, 10 Jun 2014; 

Cookie : tfapp=ld29da4a798a90186fld4bfce3ce2f23; 

domain=. test flightapp.com; path=/; expires=Thu, 09 Feb 2017; 

Cookie : user_segment=Prospect ; domain= . testf lightapp . com; path=/; 
expires=Wed, 08 Jan 2014; [...] 

Keyboard cache 

Keyboard cache is captured and saved in the dynamic-text . dat file. The file is located 
at / pr i vat e/var /mobile /Library /Keyboard/ dynamic-text . dat and contains 
keyboard cache, which comprises of text entered by the user. This text is cached as part of 
the device's autocorrect feature, and it was designed to autocomplete the predictive 
common words as well as cache words typed by the user on the device. The file keeps a list 
of approximately 600 words per language that are used on the iOS device. Commonly, this 
file is the only source of the artifact should the data be inaccessible, encrypted, or 
permanently deleted from the iOS device. 

The dynamic-text . dat is a binary file, and it can be viewed using a hex editor. This file 
may contain passwords that are cached by the iOS device, and they can be used to achieve 
brute force attacks on the device or an encrypted backup of the device. This is sometimes 
one of the best artifacts recovered from an iOS device. 
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Photos 

Photos are stored in a directory located at /private/var/mobile/Media/DCIM/, which 
contains the photos taken with the device's built-in camera, screenshots, selfies, 
photostream, recently deleted photos, and accompanying thumbnails. Some third-party 
applications will also store photos taken in this directory. Every photo stored in the DCIM 
folder contains EXIF (Exchangeable Image File Format) data. EXIF data stored in the photo 
can be extracted using exiftool, which can be downloaded from http : / /www . sno . phy . qu 
eensu . ca/~phil/exiftool/. EXIF data may also contain the geographical information 
when a photo is tagged with the user's geo location if the user has enabled location 
permissions on the iOS device. 


Wallpaper 

The current background wallpaper set for the iOS device can be recovered from the 

LockBack.gr oundThumbnail . jpg file that is found 

in /private/var/mobile/Library/SpringBoard/LockBackgroundThumbnail . jpg. 

This is complemented with a thumbnail named in the same directory. The wallpaper 
picture may contain identifying information about the user, which could help in a missing 
persons case or an iOS device recovered from a theft investigation. 


Snapshots 

The snapshots directory contains screenshots of the most recent states of built-in 
applications at the time that they were suspended. This directory is located 
in / pr i vat e/var /mobile /Library /Caches/ Snapshots/. This file may not be accessible 
if a physical acquisition is not obtained. In this instance, carving for photos is the best 
recovery attempt. Every time an application is suspended to the background by clicking on 
the Home button, a snapshot is taken to produce a nice shrinking effect. Third-party 
applications also store the snapshot cache inside their application's folder. 
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Recordings 

The iPhone allows a user to record voice memos very easily. The recorded voice memos are 
stored in the /private/var/mobile/Media/Recordings/ directory. Recordings here 
could be used to identify a person, based on their voice, and they may also contain 
information, such as voice reminders, which won't be stored in the calendar database. 
Recordings provide a lot of information to the examiner as they are user-created and often 
not deleted. 


Downloaded applications 

Third-party applications, which are downloaded and installed from the App Store, include 
applications, such as Facebook, WhatsApp, Viber, Threema, Tango, Skype, Gmail, and 
more, contain a wealth of information that is useful for an investigation. Some third-party 
applications use the Base 6 4 encoding, which needs to be converted for viewing purposes 
as well as encryption. Applications that encrypt the database file may prevent the examiner 
from accessing the data residing in the tables. Encryption varies amongst these applications 
based on the application and iOS versions. 

A unique subdirectory GUI is created for each application that is installed on the device in 
the /private/var/mobile/Applications/ directory. Most of the files stored in the 
application's directory are in the SQLite and plist format. Each file must be examined for 
relevance. We recommend using Oxygen Forensics and IEF Mobile when possible to extract 
these artifacts quickly before going back and manually running queries and parsing the 
data. 


The Apple Watch 

Examining the Apple Watch is new and exciting. The good news is that the files found on 
the watch are similar, if not the same as those found on the iPhone. We are going to see the 
data primarily existing in the SQLite database and plist files, and this is examined by 
creating or examining an iPhone backup file. Remember that an iPhone running iOS 8.2 or 
later is the only iOS device capable of being linked to the Apple Watch. 

One unique aspect about the Apple Watch is that the data pertaining to the watch is stored 
in the mobile/Library/DeviceRegistry directory within the backup, which is shown in 
the following screenshot: 
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m 'CLJ Liuidiy (zid/ uies, i,oos,3iu 

0 I© Accounts (1 file, 256 KB) 

» © AddressBook (2 files, 4,756 KB) 

© BackBoard (0 files, 0 KB) 
t> ED BulletinBoard (4 files, 140 KB) 

0 |© Caches (7 files, 238 KB) 
t> © Calendar (2 files, 3,356 KB) 

0 © CallHistory (1 file, 36 KB) 

t> © CallHistoryDB (3 files, 168 KB) 

l> © CallHistoryTransactions (2 files, 23 KB) 

1 com.apple.itunesstored (12 files, 476 KB) 
l> © ConfigurationProfiles (15 files, 58 KB) 

t> © Cookies (68 files, 10,416 KB) 

!> © DataAccess (6 files, 11 KB) 



The Apple Watch data directory 

Here, you will find exact copies of files found on the iPhone. If the case relies upon 
determining what happened on the Apple Watch versus the iPhone, it may be impossible to 
solve. As of Watch 2.0, the files that are used by both the iPhone and the watch are exact 
copies of one another, and they do not contain status flags stating where the activity was 
initiated. This is one of the hardest topics to cover in all aspects of data synchronization. For 
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example, if you examine my iPhone backup that contains my Apple Watch data, you will 
see map information in 

mobile /Library/DeviceRegistry/NanoMaps/ GeoHi story . Maps data that occurs 
before the Apple Watch was released. This should be impossible, but it's simply because 
Apple is copying the iPhone maps database and placing a copy in the Apple Watch data 
location. The following is an example of what data in the GeoHistory . Mapsdata file looks 
like when being examined in UFED Physical Analyzer. While this tool is expensive, it is one 
of the best analytical platforms for manually carving and hunting artifacts that relate to 
your investigation. In this example, a keyword search was run for the term "current 
location" within the GeoHistory . Mapsdata file. From these results, we can ascertain that 
the user was at the address highlighted in the following screenshot when asking for or 
researching directions on the iPhone or the Watch. Remember, this is an exact copy of the 
same file, so we currently cannot say whether this location was stamped by the watch or the 
iPhone: 



The GeoHistory. Map S dat a in Physical Analyzer 


Some of the more common Apple Watch artifacts that can be recovered include the 
following: 


• AddressBook 

• GeoServices 
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• Health 

• Mail 

• Passes 

• Preferences 

• PairdSync 

• Photos 

This list is just a sample of the most popular items that we can recover data from on the 
Apple Watch. Again, these artifacts primarily exist as SQLite and plist files within the 
mobile /Library/DeviceRegistry/ directory. For Watch identifiers, the binary plist file 
located at mobile /Library/DeviceRegistry . state/properties . bin can be examined 
to determine the watch name, make, model, OS, and GUID. At the time of writing this book, 
the iPhone backup was our best method to acquire and access data from the Apple Watch. 
We can only assume that the data stored on the Apple Watch has the same hardware level 
restrictions keeping from performing JTAG on the iOS devices. However, who knows what 
the future may bring with regard to accessing this data? 


Recovering deleted SQLite records 

SQLite databases store the deleted records within the database itself, so it is possible to 
recover deleted data, such as contacts, SMS, calendar, notes, e-mail and voicemail, and more 
by parsing the corresponding SQLite database. If a SQLite database is vacuumed or 
defragmented, the likelihood of recovering the deleted data is minimal. The amount of 
cleanup that these databases require relies heavily on the iOS version, the device, and the 
user's settings on the device. 

A SQLite database file comprises one or more fixed size pages, which are used just once. 
SQLite uses a b-tree layout of pages to store indices and table content. Detailed information 
on the b-tree layout is explained at http : / /sandbox . df rws . org/2011/fox-it/DFRWS20 
1 l_re suits /Report/ Sqlite_carving_extractAndroidData . pdf. 

Commercial forensic tools provide support to recover deleted data from SQLite database 
files, but they don't always recover all of the data, nor do they support extracting data from 
all databases on an iOS device. It is recommended that each database containing key 
artifacts be examined for deleted data. The key artifacts, or databases, already discussed in 
this book, should be examined using free parses, hex viewers, or even your forensic tool to 
determine whether the user deleted artifacts that are relevant to the investigation. 

To carve a SQLite database, you can examine the data in raw hex or use sqliteparse . py, 
a free Python script developed by Mari DeGrazia. The Python script can be downloaded 
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from https : / / github . com/mdegrazia/ SQlite-Deleted-Records-Parser. 

The following example recovers the deleted records from the notes . sqlitedb file and 
dumps the output to the output . txt file. This script should work on all database files 
recovered from iOS devices. To validate your findings from running the script, simply 
examine the database in a hex viewer to ensure nothing is overlooked: 

$python sqliteparse .py -f notes . sqlitedb -r -o output.txt 

In addition to this, performing a strings dump of the database file can also reveal deleted 
records that may have been missed, as shown in the following command: 

$strings notes . sqlitedb 

Should you prefer a GUI, Mari kindly created one and placed it on her 
website az4n6 . blogspot . com. 


Summary 

This chapter covered various data analysis techniques and specified the locations for 
common artifacts within the iOS device's file system. When writing this chapter, we aimed 
to cover the most popular artifacts that tie into most investigations. Clearly, it is impossible 
to cover them all. We hope that once you learn how to extract data from SQLite and plist 
files, intuition and persistence will assist you in parsing the artifact not covered. 

Keep in mind that most open source and commercial tools are able to pull active and 
deleted data from common database files, such as contacts, calls, SMS, and more, but they 
often overlook the third-party application database files. Our best advice is to know how to 
recover the data manually, just in case you need to validate your findings or testify to how 
your tool functions. 

We covered techniques to recover deleted SQLite records that prove useful in most iOS 
device investigations. Again, the acquisition method, encoding, and encryption schemas 
can affect the amount of data that you can recover during your examination. In Chapter 3, 
iOS Forensic Tools, we introduced tools that will aid in parsing the files covered in this 
chapter. While it's nice to use a forensic tool that is capable of parsing common artifacts on 
iOS devices, the hard part is putting the puzzle together and understanding how tool 
functions. The goal of this chapter was to demonstrate how the forensic tools parse iOS 
data, how the different tools represent the data, and mainly, how to manually query the 
databases where needed. Third-party application files were touched on, but they were not 
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covered in depth in this chapter. We saved the best for last and will cover third-party 
application files in Chapter 13 , Parsing Third-Party Application Files. The next chapter 
introduces Android forensics and covers the fundamental concepts of the Android 
platform. 
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In the previous chapter, we covered various logical and physical extraction techniques. In 
physical extraction, a bit-by-bit image of the Android device is obtained, which contains 
valuable information. In this chapter, we will learn how to analyze and extract relevant 
data, such as call logs, text messages, and so on, from an image file. While the data 
extraction and analysis techniques provide information about various details, not all 
techniques can provide information about the deleted data. Data recovery is a crucial aspect 
of mobile forensics, as it helps to unearth the deleted items. This chapter aims at covering 
various techniques, which can be used by a forensic analyst to recover the data from an 
Android device. 

In this chapter, we will cover the following two major topics: 

• Analyzing and extracting data from Android image files using the open source 
tool. Autopsy 

• Various techniques to recover deleted files from the SD card and internal 
memory 


Analyzing an Android image 

The term "Android image" refers to the physical image (also called forensic image or raw 
image) that is obtained by performing any of the physical data extraction techniques. Using 
the techniques explained in Chapter 9, Android Data Extraction Techniques , you can image 
the entire /data /data block or any particular block that is of relevance to the investigation. 
Once the image is obtained, an investigator can manually go through the contents of the file 
or take advantage of the available tools to parse through the contents. Commercial tools. 
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such as Cellebrite, XRY, and so on, can drill into the data and present a comprehensive 
picture of the contents. Autopsy is one of the very widely-used open source tools in the 
forensics world that performs an excellent job of analyzing an Android image. 


Autopsy 

Autopsy is a forensic platform and acts as a GUI for the Sleuth Kit. It is available for free 
download at http : / /www . sleuthkit . org/. The Sleuth Kit is a collection of UNIX and 
Windows-based tools and utilities, which are used to perform forensic analysis. Autopsy 
displays the results by forensically analyzing a given volume and thereby helps 
investigators focus on relevant sections of the data. Autopsy is free, extensible, and it has 
several modules that can be plugged in. Autopsy can be used to load and analyze an 
Android image that is obtained after physical extraction. 


Adding an image to Autopsy 

Once you have downloaded and installed Autopsy, follow these steps to add an image to 
Autopsy: 

1. Open the Autopsy tool and select the Create New case option, as shown in 
following screenshot: 


Jp. Autopsy a. 0.0 

ile View Tools Window Help 

Close Case Add Data Source Generate Report 



Creating new case in Autopsy 
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2. Enter all the necessary case details, including the name of the case, the location 
where data needs to be stored, and so on, as shown in the following screenshot: 


New Case Information X 

Steps Case Info 

1. Case Info 

2. Additional Information 

Enter New Case Information: 

Case Name: ForensicsDemo 

Base Directory: C : VJsersVtohitVDesktopij Browse 

Case Type: (•) Single-user Multi-user 

Case data will be stored in the following directory: 

C:VJsersVtohitV3esktopforensicsDemo 


| Next > | finish ~M I Cancel 


Entering case information in Autopsy 

3. Enter the case number and examiner details and click on Finish. 

4. Now, click on the Add Data Source button, add the image file to be analyzed, 
and click on Next: 


Add Data Source 


X 


Steps 


1. Enter Data Source 
Information 

2. Configure Ingest Modules 

3. Add Data Source 


Enter Data Source Information wizard (Step 1 of 3) 


Select source type to add: Image File v 

Browse for an image file: 

C: \Users 'RohitV3esktop\sample.img Browse 

Please select the input timezone: (GMT +5:30) Asia/Calcutta v j 

I I Ignore orphan files in FAT file systems 

(faster results, although some data will not be searched) 


Press 'Next 1 to analyze the input data, extract volume and file system data, and populate a local database. 


Entering Data Source information in Autopsy 
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5. On the next screen, you can configure what modules have to be run on the 
images, as shown in the following screenshot. It is recommended to select the 
Recent Activity, Exif Parser, Keyword Search, and Android Analyzer modules. In 
the next step, click on Finish: 


M- Add Data Source 


X 


Steps 


Configure Ingest Modules wizard (Step 2 of 3) 


1. Enter Data Source Information 

2. Configure Ingest Modules 

3. Add Data Source 


Configure the ingest modules you would like to run on this data source. 


P Recent Activity 

0 Hash Lookup 

P File Type Identification 

P Embedded File Extractor 

P Exif Parser 

P Keyword Search 

P Email Parser 

p| Extension Mismatch Detector 

P EO 1 Verifier 

P Android Analyzer 

P Interesting Files Identifier 

P PhotoRec Carver 


Select All Deselect All 

P Process Unallocated Space 


Configuring modules in Autopsy 

Once this is one done, the tool usually takes a few minutes to parse through the image 
depending on its size. During this time, you might see some errors or warning messages if 
any are encountered by the tool. However, Autopsy provides the fastest access to the 
artifacts and the file system as compared to other tools. 
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Analyzing an image using Autopsy 

Once the image is loaded, expand the file present under Data Sources to see data present in 
the image. For example, the following screenshot shows the contents of the /data/data 
folder: 


ForensicsDemo - Autopsy 4.0.0 


File View Tools Window Help 


i Close Case 


Add Data Source 


h Generate Report 


Data Sources 


-- sample, img 

I— \ t SOrphanFiles (0) 
yt SUnalloc (3) 
j !Jl app-private (2) 

8 Qt data (241) 

8 X .drm (3) 

8 p android. googleSearch.googleSearchWidget (4) 
8 p com. android. apps. tag (3) 

8 p com. android. backupconfirm (4) 

8 P com. android, blue tooth (6) 

8 P com. android. browser (13) 

8 P com. android. calendar (5) 

8 P com. android. certinstaller (4) 

8 P com. android. chrome (12) 

8 p com. android. dipboardsaveservice (5) 

8 P com. android. contacts (5) 

8 ! .i- : com. android. defcontainer (4) 

8 P com. android. email (7) 

8 P com. android. exchange (4) 

8 \ com. android. facelock (3) 


A 


Directory Listing 
Data Sources 
Table Thumbnail 


Name 

~4 sample. img 


Analyzing image in Autopsy 

In the preceding example, only the /data portion of the device has been imaged. If the 
entire device is imaged, then the tool would show more volumes. Depending on the 
underlying details of the investigation, relevant portions need to be analyzed. In the 
following example, by examining the folders present under com . android . browser, we 
can extract the list of various sites visited by the user along with their dates: 
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Directory Listing 

/img_sample . img/data/com . android . browser/app_databases/localstorage 


Table Thumbnail 



Name 

Modified Time 

Change Time 

^ [current folder] 

2016-02-06 16:43:52 1ST 

2016-02-06 16:43:52 1ST 

l_. [parent folder] 

2015-06-23 21:33:42 1ST 

2015-06-23 21:33:42 1ST 

http_blog . algolia . com_0 . localstorage 

2014-05-31 10: 17:23 1ST 

2014-05-31 10:17:23 1ST 

http_blog . kotowicz. net_0 . localstorage 

2014-05-04 10:08:14 1ST 

2014-05-04 10:08:14 1ST 

http_blogs . ca . com_0 . localstorage 

2014-05-03 20:05: 13 1ST 

2014-05-03 20:05: 13 1ST 

h ttp_ct 1 . addthis . com_0 .localstorage 

2014-08-07 23:36:09 1ST 

2014-08-07 23:36:09 1ST 

http_disqus . com_0 . localstorage 

2014-07-10 22:46:59 1ST 

2014-07-10 22:46:59 1ST 

http_freshmenu . com_0 . localstorage 

2015-08-30 13:40:23 1ST 

2015-08-30 13:40:23 1ST 

h ttp jgoogleads . g . doubleclick . net_0 . localstorc 

2014-05-22 22:33:43 1ST 

2014-05-22 22:33:43 1ST 

h ttp_m . economictimes . com_0 . localstorage 

2015-11-11 10:37:33 1ST 

2015-11-11 10:37:33 1ST 

http_m . facebook. com_0 . localstorage 

2013-02-20 20:01:39 1ST 

2013-02-20 20:01:39 1ST 

http_m . fakingnews . firstpost . com_0 . localstorc 

2014-07-10 21:10:10 1ST 

2014-07-10 21: 10: 10 1ST 




} data (241) 

0- QjJ .drm (3) 

© 0 android. googleSearch.googleSearch Widget (4) 
©■• P com. android. apps. tag (3) 

1- P com. android, backupconfirm (4) 

©•• P com. android. bluetooth (6) 

0 ^ com. android. browser (13) 
app_appcache (4) 

£)• |j[ app_databases (9) 

0 i.. http_m.facebook.com_0 (5) 

i_. https_dluwhu0fkvi771.doudfront.net 
https_mail. google. com_0 (8) 
https_www.payumoney.com_0 (4) 
localstorage (65) 
app_filesystem (2) 
app_geolocation (5) 
app Jcons (4) 
app jjlugins (2) 
app_webnotification (3) 


I 


pp 


as 

# 

as 

as 

as 


as 


Analyzing browsing details in Autopsy 

Valuable data, such as text messages, browsing history, chats, call history, pictures, videos, 
location details, and so on, could be unearthed by analyzing the data presents under 
various sections. 


Android data recovery 

Data recovery is one of the most significant and powerful aspects of forensic analysis. The 
ability to recover deleted data can be crucial to crack many civil and criminal cases. From a 
normal user's point of view, recovering data that has been deleted would usually refer to 
the operating system's built-in solutions, such as the Recycle Bin in Windows. While it's true 
that data can be recovered from these locations, due to an increase in user awareness, these 
options don't often work. For instance, on a desktop computer, people now use Shift + Delete 
as a way to delete a file completely from their desktop. 
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Data recovery is the process of retrieving deleted data from a device when it cannot be 
accessed normally. Consider the scenario where a mobile phone has been seized from a 
terrorist. Wouldn't it be of greatest importance to know which items were deleted by the 
terrorist? Access to any deleted SMS messages, pictures, dialed numbers, application data, 
and more can be of critical importance, as they often reveal sensitive information. With 
Android, it is possible to recover most of the deleted data if the device files are properly 
acquired. However, if proper care is not taken while handling the device, the deleted data 
could be lost forever. To ensure that the deleted data is not overwritten, it is recommended 
to keep the following points in mind: 

• Do not use the phone for any activity after seizing it. The deleted data exists on 
the device until the space is needed by some other incoming data. Hence, the 
phone must not be used for any sort of activity so as to prevent the data from 
being overwritten. 

• Even when the phone is not used, without any intervention from our end, data 
can be overwritten. For instance, an incoming SMS would automatically occupy 
the space, which could overwrite the data marked for deletion. To prevent 
occurrence of such events, the examiner should follow the forensic handling 
methods described in the previous chapters. The easiest solution is to place the 
device in airplane mode or disable all connectivity options on the device. This 
prevents the delivery of any new messages. 

All Android file systems have metadata that contains information about the hierarchy of 
files, filenames, and so on. Deletion will not really erase this data but remove the file system 
metadata. When text messages or any other files are deleted from the device, they are just 
made invisible to the use, but the files are still present on the device. Essentially, the files are 
simply marked for deletion, but they reside on the file system until being overwritten. 
Recovering deleted data from an Android device involves two scenarios: recovering data 
that is deleted from the SD card, such as pictures, videos, application data, and more, and 
recovering data that is deleted from the internal memory of the device. The following 
sections cover the techniques that can be used to recover deleted data from both the SD card 
and the internal memory of the Android device. 
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Recovering deleted data from external SD card 

Data present on SD cards can reveal a lot of information for forensic investigators. SD cards 
are capable of storing pictures and videos taken by the phone's camera, voice recordings, 
application data, cached files, and more. Essentially, anything that can be stored on a 
computer hard drive can be stored on an SD card as much as the available space allows. 

Recovering the deleted data from an external SD card is a straightforward process. SD cards 
can be mounted as an external mass storage device and forensically acquired using 
standard digital forensic methods, as discussed in Chapter 9, Android Data Extraction 
Techniques. As mentioned in the previous chapters, SD cards in Android devices often use 
the FAT32 file system. The main reason for this is that the FAT32 file system is widely 
supported in most operating systems, including Windows, Linux, and Mac OS X. The 
maximum file size on a FAT32 formatted drive is around 4 GB. With increasingly high 
resolution formats now available, this limit is commonly reached. Apart from this, FAT32 
can be used on partitions that are less than 32 GB in size. Hence, the exFAT file system, 
which overcomes these problems, is now being used in some of the devices. 

Recovering the deleted data from an external SD card can be easily accomplished if it can be 
mounted as a drive. Hence, if the SD card is removable, connect it to workstation using a 
write blocker for acquisition. Examiners must understand that Android devices might use 
space on the SD card to cache application data; therefore, it is important to make sure that 
as much data as possible is obtained from the device prior to removing the SD card. Some 
of the older devices automatically mount the device as a drive when connected through 
USB. It is a sound forensic practice to not work directly on the device for the purpose of 
data extraction, data recovery, and so on. Hence, a physical image of the SD card needs to 
be taken and all required analysis is performed on the image itself. It is recommended to 
acquire the SD card through the device as well as separately to ensure that all data is 
obtained. To achieve the SD card image, dd through adb can be used while the device is 
running to obtain an image of the SD card of the device if the device cannot be powered off 
due to possible evidence running in the memory. If the SD card is removed and connected 
to the workstation through a card reader, it appears as external mass storage and then can 
be imaged using the standard forensic techniques described in earlier chapters. 

Once the image is obtained, it can be analyzed using any standard forensic tools, such as 
FTK Imager. FTK Imager is a simple tool that can be used to create and analyze disk images. 
It is available for download at 

http : / / accessdata . com/ product -download/ digital- forensics/ ftk-imager-ver 
sion-3 .2.0. 
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The following is a step-by-step process to recover the deleted files from an SD card image 
using FTK Imager: 

1. Start FTK Imager and click on File and then click on Add Evidence Item in the 
menu: 


□ AccessData FTK Imager 3.2.0.0 

File I View Mode Help 
Add Evidence Item... 

& Add AJI Attached Devices 
% Image Mounting... 

Remove Evidence Item 
Remove All Evidence Items 
(151 Create Disk Image... 

Q Exgort Disk Image... 

1=3 Export Logical Image (ADI)... 


Adding evidence in FTK Imager 

2. Select as Image File as the evidence type in the Select Source dialog and click 
on Next: 
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3. In the Select File dialog, go to the location where the SDCARD . dd SD card image 
file is present, select it, and click on Finish: 


ScWct R« X 

Evidence Source 5etecfion 

FVase erterthe source path 

|C Uteri Ychl 555 Dwkioo SDCARD dd | 

Btowm 


< Back | Prah | Oncd | He*. 


Selecting the image file for analysis in FTK Imager 

The contents of the SD card image are then shown in the View pane. You can browse 
through the folders by clicking on the + sign. When a folder is highlighted, the contents are 
shown on the right pane. When a file is selected, its contents can be seen in the bottom pane. 
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As shown in the following screenshot, the deleted files are also shown with a red X over the 
icon: 
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Deleted files shown with a red cross over the icons in FTK Imager 

To copy the deleted files to the workstation, right-click on the marked file and select Export 
Files, as shown in the following screenshot: 
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Recovering deleted images in FTK Imager 
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It is also recommended to check whether the device has any backup applications or files 
installed. The initial release of Android did not include a mechanism for the users to back 
up their personal data. Hence, several backup applications were used extensively by the 
users. Using these apps, users have the ability to back up their data either to the SD card or 
to the cloud. For example, the Super Backup app contains the options to back up call logs, 
contacts, SMS, and more, as shown in the following screenshot: 



The Super Backup Android app 

Upon detection of a backup application, the forensic examiners must attempt to determine 
where the data is stored. Usually, the backup folder path is the internal SD card. The folder 
path is also present in the backup app's settings. The data saved in a backup may contain 
important information and thus, looking for any third-party backup app on the device 
would be very helpful. 


Recovering data deleted from internal memory 

Recovering files that are deleted from Android's internal memory (such as SMS, contacts, 
app data, and more) is not supported by all analytical tools and may require manual 
carving. Unlike some media containing common file systems, such as SD cards, the file 
system may not be recognized and mounted by forensic tools. Also, the examiner cannot get 
access to the raw partitions of the internal memory of an Android phone unless the phone is 
rooted. The following are some of the other issues that the examiner may face when 
attempting to recover data from the internal memory on Android devices: 
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• To get access to the internal memory, you can try to root the phone. However, the 
rooting process might involve writing some data to the /data partition, and this 
process could overwrite the data of value on the device. 

• Unlike SD cards, the internal file system here is not FAT32 (which is widely 
supported by forensic tools). The internal file system could be YAFFS2 (in older 
devices), EXT3, EXT4, RFS, or something proprietary built to run on Android. 
Therefore, many of the recovery tools designed for use with Windows file 
systems won't work. 

• Application data on Android devices is commonly stored in the SQLite format. 
While most forensic tools provide access to the database files, they may have to 
be exported and viewed in a native browser. The examiner must examine the raw 
data to ensure that the deleted data is not overlooked by the forensic tool. 

The discussed reasons make it difficult, but not impossible, to recover the deleted data from 
the internal memory. The internal memory of Android devices holds a bulk of the user data 
and the possible keys to your investigation. As previously mentioned, the device must be 
rooted in order to access the raw partitions. Most of the Android recovery tools on the 
market do not highlight the fact that they only work on rooted phones. Let's now take a 
look at how we can recover deleted data from an Android phone. 


Recovering deleted files by parsing SQLite files 

Android uses SQLite files to store most data. Data related to text messages, e-mails, and 
certain app data is stored in SQLite files. SQLite databases can store deleted data within the 
database itself. Files marked for deletion by the user no longer appear in the active SQLite 
database files. Therefore, it is possible to recover the deleted data, such as text messages, 
contacts, and more. There are two areas within a SQLite page that can contain deleted data: 
unallocated blocks and free blocks. 

Most of the commercial tools that recover deleted data scan the unallocated blocks and free 
blocks of the SQLite pages. Parsing the deleted data can be done using the available forensic 
tools, such as Oxygen Forensics SQLite Viewer. The trial version of the SQLite Viewer can 
be used for this purpose; however, there are certain limitations on the amount of data that 
you can recover. You can write your own script to parse the files for deleted content, and 
for this, you need to have a good understanding of the SQLite file format. The 
link http : //www . sqlite . org/ file format . html is a good place to start. If you do not 
want to reinvent and want to reuse the existing scripts, you can try the available open 
source Python scripts 

(http : //az4n6 . blog spot .in/2013/ 11/python-parser-to-recover-deleted-sqli 

te . html) to parse the SQLite files for deleted records. 
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For our example, we will recover deleted SMSes from an Android device. Recovering 
deleted SMSes from an Android phone is quite often requested as part of forensic analysis 
on a device mainly because text messages contain data, which can reveal a lot of 
information. There are different ways to recover deleted text messages on an Android 
device. First, we need to understand where the messages are being stored on the device. In 
Chapter 9, Android Data Extraction Techniques, we explained the important locations on the 
Android device where user data is stored. Here is a quick recap of this: 

• Every application stores its data under the /data /data folder (again, this 
requires root access to acquire data) 

• The files under the 

location, /data/data/ com . android . providers . telephony/ databases, 

contain details about the SMS/MMS 

Under the mentioned location, text messages are stored in a SQLite database file, which is 
named mmssms . db. Deleted text messages can be recovered by examining this file. Here are 
the steps to recover deleted SMSes using the mmssms . db file: 

1. On the Android device, enable the USB debugging mode and connect the device 
to the forensic workstation. Using the adb command-line tool, extract 
the databases folder present at /data/data/ by issuing the adb pull 
command: 


C : \android-sdk\platform-tools>adb.exe pull /data/data/com. android. providers . telephony/databases C : \temp 
pull: building file list... 

pull : /data/data/ com . android . providers . telephony/databases/telephony . db- journal - > C : \temp/telephony . db- journal 

pull: /data/dat a/com. android. providers. telephony/databases/telephony .db -> C : \temp/telephony .db 

pull: /data/dat a/com. android. providers . telephony/databases/nwk_info.db- journal -> C:\temp/nwk_info.db- journal 

pull: /data/data/com. android. providers. telephony/databases/nwk_info.db -> C : \temp/nwk_info.db 

pull : /data/data/com. android. providers. telephony/databases/mmssms .db-shm -> C : \temp/mmssms . db-shm 

pull : /data/data/com . android . providers .telephony/databases/mmssms . db-wal - > C : \temp/ mmssms . db-wal 

pull: /data/data/com. android. providers. telephony/databases/mmssms. db -> C:\temp/mmssms.db 

7 files pulled. 0 files skipped. 

3242 KB/s (6177288 bytes in 1.860s) 


O Once the files are extracted to the local machine, use the Oxygen Forensics 
SQLite Viewer tool to open the mmssms . db file. 

2. Click on the table named sms and observe the current message under the Tables 
data tab in the tool. 

3. One way to view the deleted data is by clicking on the Blocks containing deleted 
data tab, as shown in the following screenshot: 
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Recovering deleted SMS messages 

Similarly, other data residing on Android devices that store data in SQLite files can be 
recovered by parsing for deleted content. When the preceding method doesn't provide 
access to the deleted data, the examiner should look at the file in raw hex file for data 
marked as deleted, which can be manually carved and reported. 


Recovering files using file carving techniques 

File carving is an extremely useful method in forensics because it allows data that has been 
deleted or hidden to be recovered for analysis. In simple terms, file carving is the process of 
reassembling computer files from fragments in the absence of file system metadata. In file 
carving, specified file types are searched for and extracted across the binary data to create a 
forensic image of a partition or an entire disk. File carving recovers files from the 
unallocated space in a drive based merely on file structure and content without any 
matching file system metadata. Unallocated space refers to the part of the drive that no 
longer holds any file information indicated by the file system structures, such as the file 
table. 
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Files can be recovered or reconstructed by scanning the raw bytes of the disk and 
reassembling them. This can be done by examining the header (the first few bytes) and 
footer (the last few bytes) of a file. 

File carving methods are categorized based on the underlying technique in use. The header- 
footer carving method relies on recovering the files based on their header and footer 
information. For instance, the JPEG files start with Oxf fd8 and end with Oxf fd9. The 
locations of the header and footer are identified and everything between those two 
endpoints is carved. Similarly, the carving method based on the file structure uses the 
internal layout of a file to reconstruct the file. However, the traditional file-carving 
techniques, such as the ones that we've already explained, may not work if the data is 
fragmented. To overcome this, new techniques, such as smart carving use the fragmentation 
characteristics of several popular file systems to recover the data. 

Once the phone is imaged, it can be analyzed using tools, such as Scalpel. Scalpel is a 
powerful open source utility to carve files. This tool analyzes the block database storage, 
identifies the deleted files, and recovers them. Scalpel is file system-independent and is 
known to work on various file systems, including FAT, NTFS, EXT2, EXT3, HFS, and more. 
More details about Scalpel can be found at https : //github . com/sleuthkit/scalpel. 
The following steps explain how to use Scalpel on an Ubuntu workstation: 

1. Install Scalpel on the Ubuntu workstation using the sudo apt-get install 
scalpel command. 

2. The scalpel . conf file present under the /etc/scalpel directory contains 
information about the supported file types, as shown in the following screenshot: 
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The scalpel configuration file 
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This file needs to be modified in order to mention the files that are related 

O to Android. A sample scalpel . conf file can be downloaded 

from https : //www . nowsecure . com/resources/f reetools/ #viafor 
ensics. You can also uncomment the files and save the conf file to select 
file types of your choice. Once this is done, replace the original conf file 
with the one that is downloaded. 

3. Scalpel needs to be run along with the preceding configuration file on the dd 
image being examined. You can run the tool using the command shown in the 
following screenshot by inputting the configuration file and the dd file. Once this 
command is run, the tool starts to carve the files and build them accordingly: 


~ File Edit View Search Tetminal Help 

unigeekQubuntu : - S scalpel -c /hone/unigeek/Desktop/scalpel-android.conf /home/un 
igeek/Oesktop/userdata.dd -o /home/unigeek/Desktop/rohit 
Scalpel version 1.60 

Written by Golden G. Richard III, based on Foremost 0.69. 
opening target '/home/unigeek/Desktop/userdata.dd' 
image file pass 1/2. 

/hone/unigeek/Desktop/userdata.dd: 100.0% | ************* | 3.9 mb 00:00 ETA 

Allocating work queues 

Work queues allocation complete. Building carve lists... 

Carve lists built. Workload: 

gif with header '\x47\x49\x46\x38\x37\x61* and footer "\x00\x3b'' -->0 files 
gif with header *\x47\x49\x46\x38\x39\x6l" and footer "\x00\x3b" -->2 files 
jpg with header *\xff\xd8\xf f \xe0\x00\xl0" and footer "\xff\xd9" 71 files 
Jpg with header *\xff\xd8\xff\xel" and footer "\x7f\xff\xd9" -->1 files 

png with header *\x50\x4e\x47\x3f ” and footer "\xff \xfc\xfd\xfe" Q files 

png with header *\xB9\x59\x4e\x47” and footer 71 files 

sqlitedb with header "\x53\xSl\x4c\x69\x74\x6S\x20\x66\x6f\x72\x6d\x61\x74" and 
footer 0 files 

email with header "\x46\x72\x6f \x6d\x3a" and footer "* -->0 files 

doc with header "\xd9\xcf\xll\xe9\xal\xbl\xla\xel\x09\x00’ and footer "\xdo\xcf\ 

xll\xe0\xal\xbl\xla\xel\xOO\xOO" *•> 0 files 

doc with header *\xd9\xcf\xll\xe9\xal\xbl" and footer "" --> 9 flies 
htm with header '\x3c\x68\x74\x6d\x6c" and footer "\x3c\x2f \x68\x74\x6d\x6c\x3e" 
l files 

pdf with header ’\x25\x50\x44\x46” and footer ”\x25\x45\x4f \x46\x0d" -->0 files 

pdf with header ’\x2S\xS9\x44\x46” and footer ”\x25\x45\x4f\x46\x9a" -->0 flies 

wav with header "\x52\x49\x46\x46\x3f \x3f\x3f\x3f\x57\x41\x56\x4S’ and footer 

-->0 flies 

amr with header ’\x23\x21\x41\x4d\x52" and footer "" --> 0 files 


Running the Scalpel tool on a dd file 
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4. The output folder that was specified in the preceding command now contains 
lists of folders that are based on the file types, as shown in the following 
screenshot. Each of these folders contains data that is based on the folder name. 
For instance, jpg 2-0 contains files related to the . jpg extension that has been 
recovered: 
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Output folder after running the Scalpel tool 

5. As shown in the preceding screenshot, each folder contains recovered data from 
the Android device, such as images, PDF files, ZIP files, and more. While some 
pictures are recovered completely, some are not recovered fully, as shown in the 
following screenshot: 



rohit jpg-2-0 



ret 


00000050.jpg 

00000051.jpg 

00000052.jpg 




00000054.jpg 

0000005S.jpg 

OOOOOOS6.jpg 



it 

00000058.jpg 

00000059.jpg 

00000060.jpg 


Recovered data using the Scalpel tool 
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Applications such as DiskDigger can be installed on Android devices to recover different 
types of files from both the internal memory and SD cards. DiskDigger includes support for 
JPG files, MP3 and WAV audio, MP4 and 3GP video, raw camera formats, Microsoft Office 
files (DOC, XLS, and PPT), and more. However, as mentioned earlier, the application 
requires root privileges on the Android device in order to recover the content from the 
internal memory. Thus, file-carving techniques play a very important role in recovering 
important deleted files from the device's internal memory. 

Recovering contacts using your Google account 

You can also restore the contacts on the device using the Restore Contacts option through 
the Google account that is configured on the device. This would work if the user of the 
device has previously synced their contacts using the Sync Settings option available in 
Android. This option synchronizes the contacts and other details and would store them in 
the cloud. A forensic examiner with legal authority or proper consent can restore the 
deleted contacts if they can get access to the Google account configured on the device. Once 
the account is accessed, perform the following steps to restore the data: 

1. Log in to your Gmail account. 

2. Click on Gmail in the top-left corner and select Contacts, as shown in the 
following screenshot: 



The Contacts menu in Gmail 
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3. Click on More, which is present above the contacts list. 

4. Click on Restore Contacts, and the following screen will appear: 


Restore Contacts 

You can restore your contact list to the state that it was in at any point within 
the past 30 days This is a great way to recover deleted contacts undo an 
import or undo a merge Learn more 

Please select a time to restore to 

10 minutes ago 
• 1 hour ago 
Yesterday 
1 week ago 
Custom 

|_0 days, |_1 ▼_] hours. |_0 minutes 


Restore 


The Restore Contacts dialog box 

5. You can restore the contact list to the state that it was in at any point within the 
past 30 days using this technique. 
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Summary 

Recovery of the deleted data on Android devices depends on various factors, which heavily 
rely on access to the data residing in the internal memory and SD card. While the recovery 
of deleted items from external storage, such as an SD card, is easy, the recovery of deleted 
items from the internal memory takes considerable effort. SQLite file parsing and file 
carving techniques are two methods that are used to recover deleted data extracted from an 
Android device. 

The next chapter discusses forensic analysis of Android apps, malware, and the reverse 
engineering of Android apps. 
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In the previous chapters, we covered details about iOS devices, including the file system 
structure, key artifacts, backup files, and acquisition and analysis methods. Starting with 
this chapter, we will focus on the Android platform and how to perform forensics on 
Android devices. Having a good understanding of the Android ecosystem, security 
constraints, file systems, and other features proves useful during forensic investigation. 
Gaining knowledge of these fundamentals would help a forensic expert to take informed 
decisions while conducting an investigation. 

We will cover the following topics in this chapter: 

• Android models 

• Android security 

• The Android file hierarchy 

• The Android file system 


The evolution of Android 

Before we take a dive into the ocean of Android, let's first spend some time discussing the 
evolution of Android, or what we call The Android Story. Back in 2005, Google started 
investing money in start-up companies that it thought would be profitable in the future. 
Android Inc., founded in 2003 by Andy Rubin, Rich Miner, Nick Sears, and Chris White, 
was one such company acquired by Google that later turned out to be the best deal ever. 
During its first two years. Android Inc. operated under secrecy. It described itself as a 
company making software for mobile phones. Rubin later stayed with Google to pioneer 
Android as an operating system that revolutionized the way mobile handsets operate. With 
this acquisition it was clear that Google was eyeing the mobile phone market. At Google, 
Rubin, along with his team, developed a powerful and flexible operating system built on a 
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Linux kernel. There was speculation everywhere about what Google was trying to do. Some 
reported that Google was trying to incorporate search and other applications into mobile 
handsets. A few others reported that Google was developing its own mobile handset. 

Finally in 2007, Open Handset Alliance (OHA), a group of technology companies, device 
manufacturers, chipset makers, and wireless carriers, was formed with the main objective of 
proposing open standards for the mobile platform. Together, they developed Android— the 
first open and free mobile platform built on Linux kernel 2.6. Later in 2008, HTC Dream was 
released, which was the first phone to run the Android operating system. After that, it was 
a dream run for Android, with its market share increasing exponentially over the next few 
years. At the time of writing this book. Android remains by far the most used OS 
throughout the world. According to IDC, in the second quarter of 2015, Android dominated 
the industry with 82.8% market share. Since its release in 2007, Android has come up with 
various versions. The most recent major Android update is Android 6.0, 
dubbed Marshmallow, which was released in October 2015. Several versions of its Linux- 
based OS have been released in alphabetical order. 

The version history of Android can be found at 

http : / / f aqoid . com/advisor/ android-versions . php, an overview of which is shown 
in the following table: 


Version 

Version name 

Release year 

Android 1.0 

Apple pie 

2008 

Android 1.1 

Banana bread 

2009 

Android 1.5 

Cupcake 

2009 

Android 1.6 

Donut 

2009 

Android 2.0 

Eclair 

2009 

Android 2.2 

Froyo 

2010 

Android 2.3 

Gingerbread 

2010 

Android 3.0 

Honeycomb 

2011 

Android 4.0 

Ice Cream Sandwich 

2011 

Android 4.1 

Jelly Bean 

2012 

Android 4.4 

KitKat 

2013 

Android 5.0 

Lollipop 

2014 

Android 6.0 

Marshmallow 

2015 
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The Android model 

To effectively understand the forensic concepts of Android, it would be helpful to have a 
basic understanding of the Android architecture. Just like a computer, any computing 
system that interacts with the user and performs complicated tasks requires an operating 
system to handle the tasks effectively. This operating system (whether it's a desktop 
operating system or a mobile phone operating system) takes the responsibility of managing 
the resources of the system and to provide a way for the applications to talk to the 
hardware or physical components to accomplish certain tasks. Android is currently the 
most popular mobile operating system designed to power mobile devices. You can find out 
more about this at http : / / developer . android . com/ about/ android . html. 

Android is open source and the code is released under the Apache license. Practically, this 
means anyone (especially device manufacturers) can access it, freely modify it, and use the 
software according to the requirements of any device. This is one of the primary reasons for 
its wide acceptance. Notable players that use Android include Samsung, HTC, Sony, and 
LG. 

As with any other platform. Android consists of a stack of layers running one above the 
other. To understand the Android ecosystem, it's essential to have a basic understanding of 
what these layers are and what they do. The following figure summarizes the various layers 
involved in the Android software stack: 
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Android architecture referenced from http : / / at iqurrehman . com/wp-content /uploads / 2013/09/ and 

ro id-arch . png 

Each of these layers performs several operations that support specific operating system 
functions. The functions and operations of the layers are explained in depth at 

http : / / www . android-app-market . com/ android-architecture . html. Each layer 
provides services to the layers lying on top of it. 


The Linux kernel layer 

Android OS is built on top of the Linux kernel with some architectural changes made by 
Google. There are several reasons for choosing the Linux kernel. Most importantly, Linux is 
a portable platform that can be compiled easily on different hardware. The kernel acts as an 
abstraction layer between the software and hardware present on the device. Consider the 
case of a camera click. What happens when you take a photo using the camera button on 
your device? At some point, the hardware instruction (pressing a button) has to be 
converted to a software instruction (to take a picture and store it in the gallery). The kernel 
contains drivers to facilitate this process. When the user presses on the button, the 
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instruction goes to the corresponding camera driver in the kernel, which sends the 
necessary commands to the camera hardware, similar to what occurs when a key is pressed 
on a keyboard. In simple words, the drivers in the kernel command control the underlying 
hardware. As shown in the preceding figure, the kernel contains drivers related to Wi-Fi, 
Bluetooth, USB, audio, display, and so on. 

The Linux kernel is responsible for managing the core functionality of Android, such as 
process management, memory management, security, and networking. Linux is a proven 
platform when it comes to security and process management. Android has taken leverage 
of the existing Linux open source OS to build a solid foundation for its ecosystem. Each 
version of Android has a different version of the underlying Linux kernel. The Lollipop 
Android version is known to use Linux kernel 3.16.1, whereas the Marshmallow version is 
known to use Linux kernel 3.18.10. 


Libraries 

The next layer in the Android architecture consists of Android's native libraries. The 
libraries are written in the C or C++ language and help the device to handle different kinds 
of data. For example, the SQLite libraries are useful for storing and retrieving the data from 
a database. Other libraries include Media Framework, WebKit, Surface Manager, and SSL. 
The Media Framework library acts as the main interface to provide a service to the other 
underlying libraries. The WebKit library provides web pages in web browsers, and the 
surface manager maintains the graphics. In the same layer, we have Android Runtime, 
which consists of the Dalvik virtual machine (DVM) and core libraries. The Android 
runtime is responsible for running applications on Android devices. The term "runtime" 
refers to the lapse in time from when an application is launched until it is shut down. 


Dalvik virtual machine 

All the applications that you install on the Android device are written in the Java 
programming language. When a Java program is compiled, we get bytecode. A virtual 
machine is an application that acts as an operating system, that is, it is possible to run a 
Windows OS on a Mac or vice versa using a virtual machine. JVM is one such virtual 
machine that can execute the previously mentioned bytecode. But, Android versions before 
5.0 use something called Dalvik virtual machine (DVM) to run their applications. 

DVM runs Dalvik bytecode, which is Java bytecode converted by the Dex compiler. Thus, 
the . class files are converted to dex files using the dx tool. Dalvik bytecode, when 
compared with Java bytecode, is more suitable for low-memory and low-processing 
environments. Also, note that JVM's bytecode consists of one or more . class files 
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depending on the number of Java files that are present in an application, but Dalvik 
bytecode is composed of only one dex file. Each Android application runs its own instance 
of DVM. This is a crucial aspect of Android security and will be addressed in detail 
in Chapter 8, Android Forensic Setup and Pre Data Extraction Techniques. 

The following figure provides an insight into how Android's DVM differs from Java's JVM: 



JVM versus DVM 


Android Runtime (ART) 

From Android 5.0 Lollipop version, Dalvik was replaced by Android Runtime (ART). As 
discussed previously, earlier versions of Android used trace-based just-in-time (JIT) 
compilation with Dalvik. In trace-based JIT, frequently executed operations are identified 
and dynamically compiled to native machine code. This native execution of these frequently 
used bytecodes called traces provides significant performance improvements. Unlike 
Dalvik, ART uses ahead-of-time (AOT) compilation which compiles entire applications into 
native machine code upon their installation. This would automatically increase the install 
time for an application but a major advantage is that this eliminates Dalvik's interpretation 
and trace-based JIT compilation, and thereby increases the efficiency and also reduces 
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power consumption. ART uses a utility called dex2oat that accepts DEX files as input and 
generates a compiled app executable for the target device. With ART, the . odex (optimised 
dex) files are replaced with the Executable and Linkable Format (ELF) executables. 

The Application Framework layer 

The application framework is the layer responsible for handling the basic functioning of a 
phone, such as resource management, handling calls, and so on. This is the block with 
which the applications installed on the device directly talk to it. The following are some of 
the important blocks in the application framework layer: 

• Telephony manager: This block manages all the voice calls 

• Content provider: This block manages the sharing of data between different 
applications 

• Resource manager: This block helps manage various resources used in 
applications 


The applications layer 

The application layer is the topmost layer where the user can interact directly with the 
device. There are two kinds of application— preinstalled applications and user-installed 
applications. Preinstalled applications, such as Dialer, Web Browser, Contacts, and more, 
come along with the device. User-installed applications can be downloaded from different 
places, such as Google Play Store, Amazon Marketplace, and so on. Everything that you see 
on your phone (contacts, mail, camera, and so on) is an application. 


The Android security 

Android was designed with a specific focus on security. Android as a platform offers and 
enforces certain features that safeguard the user data present on the mobile through 
multilayered security. There are certain safe defaults that will protect the user and certain 
offerings that can be leveraged by the development community to build secure applications. 
The following are issues that are to be kept in mind while incorporating the Android 
security controls: 

• Protecting user-related data 

• Safeguarding the system resources 

• Making sure that one application cannot access the data of another application 
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The next few sections will help us understand more about Android's security features and 
offerings. 

O A detailed explanation on Android security can be found at 

http: // source . android. com/devices/tech/security/. 


Secure kernel 

Linux has evolved as a trusted platform over the years, and Android has leveraged this fact 
using it as its kernel. The user-based permission model of Linux has in fact worked well for 
Android. As mentioned earlier, there is a lot of specific code built into the Linux kernel. 
With each Android version release, the kernel version has also changed. The following table 
shows Android versions and their corresponding kernel versions: 


Android version 

Linux kernel version 

1 

2.6.25 

1.5 

2.6.27 

1.6 

2.6.29 

2.2 

2.6.32 

2.3 

2.6.35 

3.0 

2.6.36 

4.0 

3.0.1 

4.1 

3.0.31 

4.2 

3.4.0 

4.2 

3.4.39 

4.4 

3.8 

5.0 

3.16.1 

6.0 

3.18.1 


Linux kernel versions used in Android 
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The permission model 

As shown in the following screenshot, any Android application must be granted 
permissions to access sensitive functionality, such as the Internet, dialer, and so on, by the 
user. This provides an opportunity for the user to know in advance which functionality on 
the device is being accessed by the application. Simply put, it requires the user's permission 
to perform any kind of malicious activity (stealing data, compromising the system, and so 
on). 

This model helps the user to prevent attacks, but if the user is unaware and gives away a lot 
of permissions, it leaves them in trouble (remember, when it comes to installing malware on 
any device, the weakest link is always the user). 


' 3 ' * ^..ll ■ 11:04 

A Gmail 


Do you want to install this application? 

Allow this application to: 

• Your personal information 

read contact data, write contact data 

• Network communication 

full Internet access 

• Your accounts 

Google mail, manage the accounts 
list use the authentication 
credentials of an account 

• Storage 

modify/delete USB storage contents 

• System tools 

prevent phone from sleeping, write 
subscribed feeds, wrrte sync settings 


Show all 


Cancel Install 

Cd) dzi 


The permission model in Android 
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Until Android 6.0, users needed to grant the permissions during install time. Users had to 
either accept all the permissions or not install the application. But, starting from Android 
6.0, users grant permissions to apps while the app is running. This new permission system 
also gives the user more control over the app's functionality by allowing the user to grant 
selective permissions. For example, a user can deny a particular app to access his location 
but provide access to Internet. The user can revoke the permissions at any time, by going to 
the app's Settings screen. 

Application sandbox 

In Linux systems, each user is assigned a unique user ID (UID), and users are segregated so 
that one user cannot access the data of another user. However, all applications under a 
particular user are run with the same privileges. Similarly, in Android, each application 
runs as a unique user. In other words, a UID is assigned to each application and is run as a 
separate process. This concept ensures an application sandbox at the kernel level. The 
kernel manages the security restrictions between the applications by making use of existing 
Linux concepts, such as UID and GID. If an application attempts to do something malicious, 
say to read the data of another application, this is not permitted as the application does not 
have the user privileges. Hence, the operating system protects an application from accessing 
the data of another application. 


Secure inter-process communication 

Android offers secure inter-process communication through which one's activity in an 
application can send messages to another activity in the same application or a different 
application. To achieve this. Android provides inter-process communication (IPC) 
mechanisms: intents, services, content providers, and so on. 


Application signing 

It is mandatory that all of the installed applications be digitally signed. Developers can 
place their applications in Google's Play Store only after signing the applications. The 
private key with which the application is signed is held by the developer. Using the same 
key, a developer can provide updates to their application, share data between the 
applications, and so on. 
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Security-Enhanced Linux 

Security-Enhanced Linux (SELinux) is a new security feature introduced in Android 4.3 
and fully enforced in Android 5.0. Until this addition. Android security was based 
on Discretionary Access Control (DAC), which means applications can ask for 
permissions, and users can grant or deny those permissions. Thus, malware can create 
havoc on the phones by gaining those permissions. But SE Android uses Mandatory Access 
Control (MAC), which ensures that applications work in isolated environments. Hence, 
even if a user installs a malware app, the malware cannot access the OS and corrupt the 
device. SELinux is used to enforce MAC over all the processes, including the ones running 
with root privileges. SELinux operates on the principle of default denial-anything that is not 
explicitly allowed is denied. SELinux can operate in one of the two global 
modes: permissive mode, in which permission denials are logged but not enforced, 
and enforcing mode, in which denials are both logged and enforced. More details about 
SELinux can be found at https : / /source . android . com/ security/ selinux/ concepts 
. html. 


Full disk encryption 

With Android 6.0 Marshmallow, Google has mandated full disk encryption for most 
devices, provided that the hardware meets certain minimum standards. Encryption is the 
process of converting data into cipher text using a secret key. On Android devices, full disk 
encryption refers to the process of encrypting all user data using a secret key. Once a device 
is encrypted, all user-created data is automatically encrypted before writing it to disk and 
all reads automatically decrypt data before returning it to the calling process. Full disk 
encryption in Android works only with an Embedded Multimedia Card (eMMC) and a 
similar flash devices that present themselves to the kernel as block devices. 
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The Android file hierarchy 

In order to perform forensic analysis on any system (desktop or mobile), it's important to 
understand the underlying file hierarchy. A basic understanding of how Android organizes 
its data in files and folders helps a forensic analyst narrow down their research to specific 
issues. Just like any other operating system. Android uses several partitions. This chapter 
provides an insight into some of the most significant partitions and the content stored in 
them. 

It's worth mentioning again that Android uses the Linux kernel. Hence, if you are familiar 
with Unix-like systems, you will understand the file hierarchy in Android very well. For 
those who are not very well acquainted with the Linux model, here is some basic 
information: in Linux, the file hierarchy is a single tree with the top of the tree being 
denoted as / (called the "root"). This is different from the concept of organizing files in 
drives (as with Windows). Whether the file system is local or remote, it will be present 
under the root. The Android file hierarchy is a customized version of this existing Linux 
hierarchy. Based on the device manufacturer and the underlying Linux version, the 
structure of this hierarchy may have a few insignificant changes. The following is a list of 
important folders that are common to most Android devices. Some of the folders listed are 
only visible through root access. Rooting is the process of gaining privileged access on an 
Android device. More details about rooting and executing the adb commands (which are 
shown in the following bullets) are covered in detail in Chapter 8, Android Forensic Setup 
and Pre Data Extraction Techniques. 

• /boot: As the name suggests, this partition has the information and files required 
for the phone to boot. It contains the kernel and RAM disk, and so without this 
partition the phone cannot start its processes. Data residing in RAM is rich in 
value and should be captured during a forensic acquisition. 

• /system: This partition contains system-related files other than the kernel and 
RAM disk. This folder should never be deleted as that will make the device 
unbootable. The contents of this partition can be viewed using the following 
command: 
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root(3android : /data # cd /system 

root@android : /system # Is 

CSCVersion.txt 

SW_Conf iguration . xml 

app 

bin 

build . prop 
cameradata 
esc 

csc_contents 

etc 

tonts 

framework 

hdic 

lib 

media 

sipdb 

tts 

usr 

vendor 

voicebargeindata 

vsc 

twakeupdata 

wallpaper 

xbin 


• /recovery: This is designed for backup purposes and allows the device to boot 
into recovery mode. In recovery mode, you can find tools to repair your phone 
installation. 

• /data: This is the partition that contains the data of each application. Most of the 
data belonging to the user, such as the contacts, SMSs, and dialed numbers, is 
stored in this folder. This folder has significant importance from a forensic point 
of view as it holds valuable data. The contents of the data folder can be viewed 
using the following command: 
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noot@andnoid:/ # cd /data 
root@android:/data # Is 
ISP_CV 

TMAudioSocketClient 

TMAudioSocketServer 

anr 

app 

app-asec 

app-private 

backup 

baro.dat 

cfw 

clipboard 

dalvik-cache 

data 

dontpanic 

drm 

fotatest 
gldata . sto 
gps 

hidden_volume . txt 
lbsdata-000. sto 
local 
log 

lost+found 

media 

misc 


• /cache: This is the folder used to store the frequently accessed data and some of 
the logs for faster retrieval. The cache partition is also important to the forensic 
investigation as the data residing here may no longer be present in the /data 
partition. 
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• /mi sc: As the name suggests, this folder contains information about 
miscellaneous settings. These settings mostly define the state of the device, that is 
on/off. Information about hardware settings, USB settings, and so on, can be 
accessed from this folder. 

• / sdcard: This is the partition that holds all the information present on the SD 
card. It is valuable as it can contain information such as pictures, videos, files, 
documents, and so on. 


The Android file system 

Understanding the file system is one essential part of forensic methodologies. Knowledge 
about properties and the structure of a file system proves to be useful during forensic 
analysis. The file system refers to the way data is stored, organized, and retrieved from a 
volume. A basic installation may be based on one volume split into several partitions; here, 
each partition can be managed by a different file system. As is true in Linux, Android 
utilizes mount points and not drives (that is, C : or E : ). Each file system defines its own 
rules for managing the files in the volume. Depending on these rules, each file system offers 
a different speed for file retrieval, security, size, and so on. Linux uses several file systems 
and so does Android. From a forensic point of view, it's important to understand which file 
systems are used by Android and to identify the file systems that are of significance to the 
investigation. For example, the file system that stores the user's data is of primary concern 
to us as against a file system used to boot the device. 
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Viewing file systems on an Android device 

The file systems supported by the Android kernel can be determined by checking the 
contents of the filesystems file in the proc folder. The content of this file can be viewed 
using the following command: 


root@android : / # cat /proc/filesystems 


nodev 

sysfs 

nodev 

rootfs 

nodev 

bdev 

nodev 

proc 

nodev 

cgroup 

nodev 

tmpfs 

nodev 

binfmt_misc 

nodev 

debugfs 

nodev 

sockfs 

nodev 

usbfs 

nodev 

pipefs 

nodev 

anon_inodefs 

nodev 

devpts 


ext2 


ext3 


ext4 

nodev 

ramf s 


vfat 


msdos 

nodev 

ecryptfs 

nodev 

fuse 


fuseblk 

nodev 

fusectl 


exfat 


In the preceding output, the first column tells us whether the file system is mounted on the 
device. The ones with the nodev property are not mounted on the device. The second 
column lists all the file systems present on the device. A simple mount command displays 
different partitions available on the device, as follows: 
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root@android:/ # mount 

rootfs / rootfs ro,relatime 0 0 

tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0 

devpts /dev/pts devpts rw, relatime,mode=600 0 0 

proc /proc proc rw,relatime 0 0 

sysfs /sys sysfs rw,relatime 0 0 

none /acct cgroup rw^elatime^puacct 0 0 

tmpfs /mnt/asec tmpfs rw J relatime J mode=755,gid=1000 0 0 

tmpfs /mnt/obb tmpfs rw, relatime,mode=755,gid=1000 0 0 

none /dev/cpuctl cgroup rw,relatime,cpu 0 0 

/dev/block/mmcblk0p9 /system ext4 ro J noatime,barrier=l,data=ordered 0 0 

/dev/block/mmcblk0p3 /efs ext4 rw,nosuid J nodev,noatime,barrier=l, journalasynccommit ,data=ordered 0 0 
/dev/block/mmcblk0p8 /cache ext4 rw,nosuid,nodev,noatime,errors=panic,barrier=l, journal_async_commit,data=ordered 0 0 
/dev/block/mmcblk0pl2 /data ext4 rw J nosuid J nodev,noatime,barrier=l J journal_async_commit,data=ordered J noauto_da_alloc, discard 0 0 
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0 

/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,noexec,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0 


The following is a brief overview of the important file systems 

• The root file system (rootfs) is one of the main components of Android and 
contains all the information required to boot the device. When the device starts 
the boot process, it needs access to many core files, and thus, it mounts the root 
file system. As shown in the preceding mount command-line output, this file 
system is mounted at / (root folder). Hence, this is the file system on which all 
the other file systems are slowly mounted. If this file system is corrupt, the device 
cannot be booted. 

• The sysfs file system mounts the /sys folder, which contains information about 
the configuration of the device. The following output shows various folders 
under the sys directory in an Android device: 


root@android : / # cd /sys 

root@android:/sys # Is 

block 

bus 

class 

dev 

devices 

firmware 

fs 

kernel 

module 

power 


Since the data present in these folders is mostly related to configuration, this is not usually 
of much significance to a forensic investigator. But, there can be some circumstances where 
we might want to check whether a particular setting was enabled on the phone, and 
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analyzing this folder could be useful under such conditions. 

O Note that each folder consists of a large number of files. Capturing this 
data through forensic acquisition is the best method to ensure that this 
data is not changed during examination. 

• The devpts file system presents an interface to the terminal session on an 
Android device. It is mounted at /dev/pts. Whenever a terminal connection is 
established, for instance, when an adb shell is connected to an Android device, a 
new node is created under / dev/pts. The following is the output showing this 
when the adb shell is connected to the device: 

shell@Android : / $ Is -1 /dev/pts 
Is -1 /dev/pts 

crw shell shell 136, 0 2013-10-26 16:56 0 

• The cgroup file system stands for control groups. Android devices use this file 
system to track their job. They are responsible for aggregating the tasks and 
keeping track of them. This data is generally not very useful during forensic 
analysis. 

• The proc file system contains information about kernel data structures, 
processes, and other system-related information under the /proc directory. For 
instance, the /sys directory contains files related to kernel parameters. 

Similarly, /proc/f ile systems displays the list of available file systems on the 
device. The following command shows all the information about the CPU of the 
device: 
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root@android : / # 

cat /proc/cpuinfo 

Processor 

ARMv7 Processor rev 0 (v7l) 

processor 

0 

BogoMIPS 

1592.52 

processor 

2 

BogoMIPS 

1990.65 

processor 

3 

BogoMIPS 

1990.65 

Features 

swp half thumb fastmult vfp edsp neon vfpv3 tls 

CPU implementer 

0x41 

CPU architecture 

7 

CPU variant 

0x3 

CPU part 

0xc09 

CPU revision 

0 

Chip revision 

0011 

Hardware 

SMDK4X12 

Revision 

000c 

Serial 



Similarly, there are many other useful files that provide valuable information 
when you traverse them. 

• The tmpf s file system is a temporary storage facility on the device that stores the 
files in RAM (volatile memory). The main advantage of using RAM is faster 
access and retrieval. But, once the device is restarted or switched off, this data 
will not be accessible anymore. Hence, it's important for a forensic investigator to 
examine the data in RAM before a device reboot happens or to extract the data 
via RAM acquisition methods. 
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Common file systems found on Android 

The Extended File System (EXT), which was introduced in 1992 specifically for the Linux 
kernel, was one of the first file systems, and it used virtual file system. EXT2, EXT3, and 
EXT4 are the subsequent versions. Journaling is the main advantage of EXT3 over EXT2. 
With EXT3, in case of an unexpected shutdown, there is no need to verify the file system. 
The EXT4 file system, the fourth extended file system, has gained significance with mobile 
devices implementing dual-core processors. The YAFFS2 file system is known to have a 
bottleneck on dual-core systems. With the Gingerbread version of Android, the YAFFS file 
system was swapped for EXT4. 

The following are the mount points that use EXT4 on Samsung Galaxy S3 mobile: 

/dev/block/itimcblk0p9 /system ext4 ro, noatime, barrier=l , data=ordered 0 0 

/dev/block/mmcblk0p3 /efs ext4 

rw, nosuid, nodev, noatime, barrier=l , journal_async_commit, data=ordered 0 0 

/dev/block/mmcblk0p8 /cache ext4 

rw, nosuid, nodev, noatime, barrier=l , journal_async_commit, data=ordered 0 0 

/dev/block/mmcblk0pl2 /data ext4 

rw, nosuid, nodev, noatime, bar rier=l , journal_async_commit , data=ordered, n 
oauto_da_alloc, discard 0 0 

VFAT is an extension to the FAT16 and FAT32 file systems. Microsoft's FAT32 file system is 
supported by most Android devices. It is supported by almost all the major operating 
systems, including Windows, Linux, and Mac OS. This enables these systems to easily read, 
modify, and delete the files present on the FAT32 portion of the Android device. Most of 
the external SD cards are formatted using the FAT32 file system. 

Observe the following output, which shows that the mount points 
/ sdcard and /secure/asec use the VFAT file system: 


root@android:/ # cd sdcard 

root@android : /sdcard # mount 

rootfs / rootfs ro,relatime 0 0 

tmpfs /dev tmpfs rw, nosuid, relatime,mode=755 0 0 

devpts /dev/pts devpts rw, relatime,mode=600 0 0 

aroc /proc proc rw,relatime 0 0 

sysfs /sys sysfs rw,relatime 0 0 

none /acct cgroup rw,relatime,cpuacct 0 0 

tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0 

tmpfs /mnt/obb tmpfs rw, relatime,mode=755,gid=1000 0 0 

none /dev/cpuctl cgroup rw,relatime,cpu 0 0 

/dev/block/mmcblk0p9 /system ext4 ro, noatime, barrier=l,data=ordered 0 0 

/dev/block/mmcblk0p3 /efs ext4 rw, nosuid, nodev, noatime, barrier=l,journal_async_commit,data=ordered 0 0 
/dev/block/mmcblk0p8 /cache ext4 rw, nosuid, nodev, noatime, errors=panic,barrier=l,journal_async_commit,data=ordered 0 0 
/dev/block/mmcblk0pl2 /data ext4 rw, nosuid, nodev, noatime, barrier=l,journal_async_commit,data=ordered,noauto_da_alloc, discard 0 0 
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0 

/dev/fuse /storage/sdcardO fuse rw, nosuid, nodev, noexec,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0 


Yet Another Flash File System 2 (YAFFS2) is an open source, single-threaded file system 
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released in 2002. It is mainly designed to be fast when dealing with the NAND flash. 
YAFFS2 utilizes OOB (out of band), and this is often not captured or decoded correctly 
during forensic acquisition, which makes analysis difficult. We will discuss this further 
in Chapter 9, Android Data Extraction Techniques. YAFFS2 was the most popular release at 
one point and is still widely used in Android devices. YAFFS2 is a log-structured file 
system. Data integrity is guaranteed even in the case of a sudden power outage. In 2010, 
there was an announcement stating that in releases after Gingerbread, devices were going 
to move from YAFFS2 to EXT4. Currently, YAFFS2 is not supported by newer kernel 
versions, but certain mobile manufacturers might still continue to support it. 

Flash Friendly File System (F2FS) was released in February 2013 to support Samsung 
devices running the Linux 3.8 kernel. F2FS relies on log-structured methods that optimize 
the NAND flash memory. The offline support features are a highlight of this file system. 
Yet, the file system is still transient and being updated. 

Robust File System (RFS) supports NAND flash memory on Samsung devices. RFS can be 
summarized as a FAT16 (or FAT32) file system where journaling is enabled through a 
transaction log. Many users complain that Samsung should stick with EXT4. RFS has been 
known to have lag times that slow down the features of Android. 


Summary 

Understanding the underlying features, file systems, and capabilities of an Android device 
proves useful in a forensic investigation. Unlike iOS, several variants of Android exist as 
many devices run the Android operating system and each may have different file systems 
and unique features. The fact that Android is open and customizable also changes the 
playing field of digital forensics. A forensic examiner must be prepared to expect the 
unexpected when handling an Android device. 

In the next chapter, we will discuss methods for accessing the data stored on Android 
devices. 
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In the previous chapter, we covered the fundamentals of Android architecture, security 
features, file systems, and other capabilities. Having an established forensic environment 
before the start of an examination is important as it ensures that the data is protected while 
the examiner maintains control of the workstation. This chapter will explain the process and 
considerations when setting up a digital forensic examination environment. It is paramount 
that the examiner maintains control of the forensic environment at all times. This prevents 
the introduction of contaminants that could affect the forensic investigation. 

We will cover the following topics in this chapter: 

• Setting up a forensic environment 

• Connecting the device and accessing it from a workstation 

• Screen lock bypass techniques 

• Gaining root access to the device 


Setting up the forensic environment for 
Android 

A forensic examiner may encounter a wide range of mobiles during their investigation over 
the course of time. Hence, it is necessary to have a basic environment setup on top of which 
he can build based on the requirement. It is also very important that the forensic expert 
maintains complete control over the environment at all times to avoid any unexpected 
situations. Setting up a proper lab environment is an essential part of the forensic process. 
The Android forensic setup usually involves the following steps: 
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1. Start with a fresh or forensically sterile computer environment. This means that 
other data is not present on the system or is contained in a manner that it cannot 
contaminate the present investigation. 

2. Install the basic software necessary to connect to the device. Android forensic 
tools and methodologies will work on Windows, Linux, and OS X platforms. 

3. Obtain access to the device. An examiner must be able to enable settings or 
bypass them in order to allow the data to be extracted from the Android device. 

4. Issue commands to the device through the methods defined in this chapter and 
in Chapter 9, Android Data Extraction Techniques. 

The following sections provide guidance on setting up a basic Android forensic 
workstation. 


The Android Software Development Kit 

The Android Software Development Kit (SDK) helps the development world to build, test, 
and debug applications to run on Android. This is achieved by providing the necessary 
tools to create the applications. But along with this, it also provides valuable documentation 
and other tools that can be of great help during the investigation of an Android device. A 
good understanding of the Android SDK will help you to get to grips with the particulars of 
a device and the data on the device. 

The Android SDK consists of software libraries, APIs, tools, emulators, 
and other reference material. It can be downloaded for free from http : // 
developer . android . com/ sdk/ index . html. 

During a forensic investigation, the SDK helps connect to and access the data on the 
Android device. The Android SDK is updated very frequently, so it's important to verify 
that your workstation also remains updated. The Android SDK can run on Windows, 

Linux, and OS X. 



The Android SDK installation 

A working installation of the Android SDK is a must during the investigation of a forensic 
device. Most websites recognize the operating system on the computer and will prompt you 
to download the correct Android SDK. Unlike Android Studio, the SDK tools package only 
includes the core SDK tools, which you can access from a command line. 
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The following is a step-by-step procedure to install the Android SDK on a Windows 7 
machine: 

1. Before you install the Android SDK, make sure that your system has Java 
Development Kit installed because the Android SDK relies on Java SE 
Development Kit (JDK). 

O JDK can be downloaded from 

http : / / www .oracle . com/technetwork/ j ava/ j avase/ downloads/ i 
ndex . html. 

2. Download the latest version of the Android SDK from http : / /developer . and 
roid. com/ sdk/installing/ index . html?pkg=tools. The installer version of 
the SDK is recommended for this purpose. 

3. Run the installer file, which we downloaded in the previous step. You will see a 
wizard window, as seen in the following screenshot. After this, run through the 
routine Next steps that you encounter. 



Android SDK Tools setup wizard 
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4. The installation location is the user's choice and must be remembered for future 
access. In this example, we will install it in the C : \ folder. Click on the Install 
button and choose the location (say, C : \android-sdk). The necessary files will 
be extracted to this folder. 

5. Open the directory (C : \android-sdk) and double-click on SDK Manager . exe 
to begin the update process. Make sure that you select Android SDK Platform 
tools and any one release platform version of Android, as shown in the following 
screenshot. Some of the items in the list are chosen by default. For instance, it is 
necessary to install the USB driver in order to work with Android devices in 
Windows. In our example, Google USB Driver is selected. Similarly, you can 
find other items under the Extras section. Accept the license and install it, as 
shown in the following screenshot: 



Android SDK license 
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This completes the Android SDK installation. You can also update the system's 
environment variables (path) by pointing to the executable files so that you can avoid 
navigating to the SDK folder every time in order to execute a command. This can be done 
by navigating to Control panel I System I Advanced Settings I Environment Variables 
and then adding an SDK path to it. 

The installation of the Android SDK on OS X and Linux may vary. Make 
sure that you follow all the steps provided with the SDK download for full 
functionality. 


An Android Virtual Device 

Once the Android SDK is installed along with the release platform, you can create an 
Android Virtual Device (also called an emulator/ A VD), which is often used by developers 
when creating new applications. However, an emulator has significance from a forensic 
perspective too. Emulators are useful when trying to understand how applications behave 
and execute on a device. This could be helpful to confirm certain findings that are 
unearthed during a forensic investigation. Also, while working on a device which is 
running on an older platform, you can design an emulator with the same platform. 
Furthermore, before installing a forensic tool on a real device, the emulator can be used to 
find out how a forensic tool works and changes content on an Android device. To create a 
new AVD (on the Windows workstation), perform the following steps: 

1. Open the command prompt (cmd . exe). Start the AVD manager from the 
command line by navigating to the path where the SDK is installed, and call 
the android tool with the avd option, as shown in the following command line. 
This would automatically open the AVD manager: 

C : \android-sdk\tools>android avd 

Alternatively, the AVD manager can also be started using the graphical 
AVD manager. To start this, navigate to the location where the SDK is 
installed (C : \android-sdk) in our example and double-click on AVD 
Manager. 
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The Android Virtual Device Manager window is as shown in the following 
screenshot: 


q Android Virtual Device Manager 


List of existing Android Virtual Devices located at C:\Users\vogella\.android\avd 


AVD Name Target Name 

No AVD available 


Platform API Level CPU/ABI 


New.. 


Edit... 

Delete- 

Repair... 

Details... 

Start... 


Refresh 


v" A valid Android Virtual Device. A repairable Android Virtual Device. 

X An Android Virtual Device that failed to load. Click 'Details' to see the error. 


Android Virtual Device Manager 
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2. Click on New in the AVD Manager window to create a new virtual device. Click 
on Edit to change the configuration of an existing virtual device as shown in the 
following screenshot: 



Virtual device configuration 


[ 263 ] 




Android Forensic Setup and Pre Data Extraction Techniques 


3. Enter the following details : 

• AVD Name: This option is used to provide a name for the virtual device, for 
example, ForensicsAVD. 

• Device: This option is used to select any device from the available options based 
on the screen size. 

• Target: This option helps you select the platform of the device. Note that only the 
versions that were selected and installed during the SDK installation will be 
shown here to be selected. 

Similarly, you can select hardware features to customize the emulator, for 
example, the size of internal storage memory, SD card, and so on. 

4. A confirmation message is shown once the device is successfully created. Now, 
select the AVD and click on Start. This will prompt you with the launch options. 
Select any option and click on Launch. 

5. This should launch the emulator. Note that this could take a few minutes or even 
longer depending on the workstation's CPU and RAM. The emulator does 
consume a significant amount of resources on the system. After a successful 
launch, the AVD will run as shown in the following screenshot: 



The Android emulator 
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From a forensic perspective, analysts and security researchers can leverage the functionality 
of an emulator to understand the file system, data storage, and so on. The data created 
when working on an emulator is stored in your home directory in a folder named 
. android. For instance, in our example, the details about the ForensicsAVD emulator that 
we created earlier are stored 

under C : \Users\Rohit\ . android\avd\ForensicsAVD . avd. Among the various files 
present under this directory, the following are the files that are of interest for a forensic 
analyst: 

• cache . img: This is the disk image of the /cache partition (remember that we 
discussed the /cache partition of an Android device in 

Chapter 7, Understanding Android). 

• sdcard . img: This is the disk image of the SD card partition. 

• Userdata-qemu . img: This is the disk image of the /data partition. The /data 
partition contains valuable information about the device user. 


Connecting an Android device to a workstation 

Forensic acquisition of an Android device using open source tools requires connecting the 
device to a forensic workstation. Forensic acquisition of any device should be conducted on 
a forensically sterile workstation. This means that the workstation is strictly used for 
forensics and not for personal use. 

Note that anytime a device is plugged into a computer, changes can be 
made to the device. The examiner must have full control of all interactions 
with the Android device at all times. 

The following steps should be performed by the examiner in order to connect the device 
successfully to a workstation. Note that write protection may prevent the successful 
acquisition of the device since commands may need to be pushed to the device in order to 
pull information. All the following steps should be validated on a test device prior to 
attempting them on real evidence. 



[ 265 ] 


Android Forensic Setup and Pre Data Extraction Techniques 


Identifying the device cable 

The physical USB interface of an Android device allows it to connect to a computer to share 
data, such as songs, videos, and photos. This USB interface might change from 
manufacturer to manufacturer and also from device to device. For example, some devices 
use mini-USB while some others use micro-USB and USB Type C. Apart from this, some 
manufacturers use their own proprietary formats, such as EXT-USB, EXT micro-USB, and so 
on. The first step in acquiring an Android device is to determine what kind of device cable 
is required. 


Installing the device drivers 

In order to identify the device properly, the computer may need certain drivers to be 
installed. Without necessary drivers, the computer may not identify and work with the 
connected device. But the issue is that since Android is allowed to be modified and 
customized by the manufacturers, there is no single generic driver that would work for all 
the Android devices. Each manufacturer writes its own proprietary drivers and distributes 
them over the Internet. So, it's important to identify specific device drivers that need to be 
installed. Of course, some of the Android forensic toolkits (which we will discuss in the 
following chapters) do come with some generic drivers or a set of most used drivers; they 
may not work with all the models of Android phones. Some Windows operating systems 
are able to autodetect and install the drivers once the device is plugged in, but more often 
than not, it fails. The device drivers for each manufacturer can be found on their respective 
websites. 


Accessing the connected device 

If you haven't done so already, connect the unlocked Android device to the computer 
directly using the USB cable. The Android device will appear as a new drive and you can 
access the files on the external storage. Some older Android devices may not be accessible 
unless the Turn on USB Storage option is enabled on the phone, as shown in the following 
screenshot: 
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USB Mass Storage 



USB connected 


You have connected to your computer via 
USB. Touch the button below if you want to 
copy files between your computer and your 
Android's USB storage 



USB mass storage 

In some Android phones (especially with HTC), the device may expose more than one 
functionality when connected with a USB cable. For instance, as shown in the following 
screenshot, when an HTC device is connected, it presents a menu with four options. The 
default selection is Charge only. When the Disk drive option is selected, it is mounted as a 
disk drive. 



HTC mobile USB options 
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When the device is mounted as a disk drive, you will be able to access the SD card present 
on the device. From a forensic point of view, the SD card has significant value as it may 
contain files that are important for an investigation. However, the core application data 
stored under /data /data will remain on the device and cannot be accessed through these 
methods. 


The Android Debug Bridge 

Considered to be one of the most crucial components in Android forensics, the Android 
Debug Bridge is a command-line tool that allows you to communicate with the Android 
device and control it. We will learn about the ADB in detail in the coming chapters; 
however, we will focus on a basic introduction to ADB for now. You can access the ADB 
tool under <sdk>/platform-tools/. 

Before we discuss anything about adb, we need to have an understanding about the USB 
debugging option. 

USB debugging 

The primary function of this option is to enable communication between the Android 
device and a workstation on which the Android SDK is installed. On a Samsung phone, you 
can access this under Settings I Developer Options, as shown in the following screenshot. 
Other Android phones may have different environments and configuration features. The 
examiner may have to force the Developer Options option by accessing build mode. 



The USB debugging option in Samsung mobiles 
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However, starting from Android 4.2, the Developer Options menu is hidden to make sure 
that users do not enable it by accident. To enable it, go to Settings I About Phone and then 
tap the Build Number field seven times. After this. Developer Options will be available in 
the Settings menu. Prior to Android 4.2.2, enabling this option was the only requirement 
of communicating with the device over adb. However, starting from Android 4.2.2, Google 
has introduced the Secure USB debugging option. This feature only allows hosts that are 
explicitly authorized by the user to connect to the device using adb. Thus, when you 
connect the device to a new workstation via USB in order to access adb, you need to first 
unlock the device and authorize access by clicking on OK in the confirmation window 
shown in the following screenshot. If Always allow from this computer is checked, the 
device will not prompt for authorization in future. 


^ J Allow USB debugging? 


The computer’s RSA key fingerprint 
is: 

23:B2:47:E1:08:DE:5A:3B:58:5A:A5:A6 

:FA:98:E0:50 

Always allow from this computer 


Cancel OK 


Secure USB debugging 

When the USB debugging option is selected, the device will run the adb daemon (adbd) in 
the background and will continuously look for a USB connection. The daemon will usually 
run under a non-privileged shell user account and thus will not provide access to the 
complete data. However, on rooted phones, adbd will run under the root account and thus 
provide access to all the data. It is not recommended to root a device to gain full access 
unless all other forensic methods fail. Should the examiner elect to root an Android device, 
the methods must be well documented and tested prior to attempting it on real evidence. 
Rooting will be discussed at the end of this chapter. 
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On the workstation where the Android SDK is installed, adbd will run as a background 
process. Also, on the same workstation, a client program will run, which can be invoked 
from a shell by issuing the adb command. When the adb client is started, it first checks if an 
adb daemon is already running. If the response is negative, it initiates a new process to start 
the adb daemon. The adb client program communicates with local adbd over port 5037. 


Accessing the device using adb 

Once the environment setup is complete and the Android device is in USB debugging 
mode, connect the Android device the forensic workstation with a USB cable and start 
using adb. 


Detecting connected devices 

The following adb command provides a list of all the devices connected to the forensic 
workstation. This will also list the emulator if it is running at the time of issuing the 
command. Also, remember that if the necessary drivers are not installed, then the following 
command will show a blank message. If you encounter that situation, download the 
necessary drivers from the manufacturer and install them. 


C : \android-sdk\platform-tools>adb . exe devices 
List of devices attached 
kdf!6ac3115e5f05 device 


Killing the local adb server 

The following command kills the local adb service: 

C : \android-sdk\platform-tools>adb . exe kill-server 

After killing the local adb service, issue the adb devices command and observe that the 
server is started, as shown in the following screenshot: 


[ 270 ] 




Android Forensic Setup and Pre Data Extraction Techniques 


C: \android-sdk\platform-tools>adb.exe devices 
List of devices attached 

* daemon not running, starting it now on port 5037 * 

* daemon started successfully * 

4dfl6ac3115e5f05 device 


Accessing the adb shell 

This command allows forensic examiners to access the shell on an Android device and 
interact with the device. 

The following is the command to access the adb shell and execute a basic 1 s command to 
see the contents of the current directory: 

C : \android-sdk\platform-tools>adb . exe shell 
shell@android : / $ Is 
Is 

acct 

cache 

config 

d 

data 

default .prop 

dev 

ef s 

etc 

factory 

f stab . smdk4xl2 
init 

init . bt . rc 
init . goldfish . rc 
init . rc 

init . smdk4xl2 . rc 
init . smdk4xl2 . usb . rc 


The Android emulator can be used by forensic examiners to execute and understand the 
adb commands before using them on the device. In Chapter 9, Android Data Extraction 
Techniques, we will explain more about leveraging adb to install applications, copy files and 
folders from the device, view device logs, and so on. 
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Handling an Android device 

Handling an Android device in a proper manner prior to the forensic investigation is a very 
important task. Care should be taken to make sure that our unintentional actions don't 
result in data modification or any other unwanted happenings. The following sections 
throw light on certain issues that need to be considered while handling the device in the 
initial stages of forensic investigation. 

With the improvements in technology, the concept of device locking has effectively 
changed over the last few years. Most users now have a passcode locking mechanism 
enabled on their device due to the increase in general security awareness. Before we look at 
some of the techniques to bypass locked Android devices, it is important not to miss an 
opportunity to disable the passcode when there is a chance. 

When an Android device, which is to be analyzed, is first accessed, check whether the 
device is still active (unlocked). If so, change the settings of the device to enable greater 
access to the device. So, when the device is still active, consider performing the following 
tasks: 


• Enabling USB debugging: Once the USB debugging option is enabled, it gives 
greater access to the device through the adb connection. This is of great 
significance when it comes to extracting data from the device. The location to 
enable USB debugging might change from device to device, but it's usually 
under Developer Options in Settings. Most methods for physically acquiring 
Android devices require USB debugging to be enabled. 

• Enabling the "Stay awake" setting: If the Stay awake option is selected and the 
device is connected for charging, then the device never locks. Again, if the device 
locks, the acquisition can be halted. 

• Increasing screen timeout: This is the time for which the device will be 
effectively active once it is unlocked. The location to access this setting varies 
depending upon the model of the device. On a Samsung Galaxy S3 phone, you 
can access the same by navigating to Settings I Display I Screen Timeout. 

Apart from this, as mentioned in Chapter 1 , Introduction to Mobile Forensics, the device 
needs to be isolated from the network to make sure that remote wipe options do not work 
on the device. The Android Device Manager allows the phone to be remotely wiped or 
locked. This can be done by signing in to the Google account, which is configured on the 
mobile. More details about this are mentioned in the following section. If the Android 
device is not set up to allow remote wiping, the device can only be locked using the 
Android Device Manager. Also, there are several Mobile Device Management (MDM) 
software products available on the market, which allow users to remotely lock or wipe the 
Android device. Some of these may not require specific settings to be enabled on the device. 
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Using the available remote wipe software, it is possible to delete all the data, including e- 
mails, applications, photos, contacts, and other files including those found on the SD card. 
To isolate the device from the network, you can put the device in airplane mode and disable 
Wi-Fi as an extra precaution. Enabling airplane mode and disabling Wi-Fi works well as the 
device will not be able to communicate over a cellular network and cannot be accessed via 
Wi-Fi. Removing the SIM card from the phone is also an option but that does not effectively 
stop the device from communicating over Wi-Fi or some other cellular networks. To place 
the device in airplane mode, press and hold the Power/Off button and select airplane 
mode. 

All these steps can be done when the Android device is not locked. ITowever, during the 
investigation, we commonly encounter devices that are locked. Flence, it's important to 
understand how to bypass the lock code if it is enabled on an Android device. 


Screen lock bypassing techniques 

Due to the increase in user awareness and the ease of functionality, there has been an 
exponential increase in the usage of passcode options to lock Android devices. Flence, 
bypassing the device's screen lock during a forensic investigation becomes increasingly 
important. The applicability of the screen lock bypass techniques discussed so far are based 
on the situation. Note that some of these methods may result in making changes to the 
device. Make sure that you test and validate all the steps listed on non-evidentiary Android 
devices. The examiner must have authorization to make the required changes to the device, 
document all steps taken, and be able to describe the steps taken if a courtroom testimony is 
required. 

Currently, there are three types of screen lock mechanisms offered by Android. Although 
there are some devices which have voice lock, face lock, and fingerprint lock options, we 
will limit our discussion to the following three options since these are most widely used on 
all Android devices: 

• Pattern lock: The user sets a pattern or design on the phone and the same must 
be drawn to unlock the device. Android was the first smartphone to introduce a 
pattern lock. 

• PIN code: This is the most common lock option and is found on many mobile 
phones. The PIN code is a 4-digit number that needs to be entered to unlock the 
device. 

• Passcode (alphanumeric): This is an alphanumeric passcode. Unlike the PIN, 
which takes four digits, the alphanumeric passcode takes more than just digits. 
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The following section details some of the techniques to bypass these Android lock 
mechanisms. Depending on the situation, these techniques might help an investigator to 
bypass the screen lock. 

Using adb to bypass the screen lock 

If USB debugging appears to be enabled on the Android device, it is wise to take advantage 
of it by connecting with adb using USB, as discussed in the earlier sections. The examiner 
should connect the device to the forensic workstation and issue the adb devices 
command. If the device shows up, it implies that USB debugging is enabled. If the Android 
device is locked, the examiner must attempt to bypass the screen lock. The following are the 
two methods that may allow the examiner to bypass the screen lock when USB debugging 
is enabled. 


Deleting the gesture.key file 

Deleting the gesture . key file will remove the pattern lock on the device. However, it's 
important to note that this will permanently change the device as the pattern lock is gone. 
This should be considered if conducting cover operations. This is how the process is done: 

1. Connect the device to the forensic workstation (a Windows machine in our 
example) using a USB cable. 

2. Open the command prompt and execute the following instructions: 

adb.exe shell 
cd /data/system 
rm gesture . key 

3. Reboot the device. If the pattern lock still appears, just draw any random design 
and observe that the device should unlock without any trouble. 

O This method works when the device is rooted. This method may not be 

successful on unrooted devices. Rooting an Android device should not be 
performed without proper authorization as the device is altered. 
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Updating the settings.db file 

To update the settings . db file, perform the following steps: 

1. Connect the device to the forensic workstation using a USB cable. 

2. Open the command prompt and execute the following instructions: 


: / $ cd /data/data/con. android. providers .settings/databases 
sqlite3 settings.db 

update systen set value=0 where nane=’ lock_pattern_autolock’ ; 
c update secure set ualue=0 where nane=* lock_pattern_autolock' ; 

4 /data/data/con.andro id . prou iders .settings/databases 

update systen set value=0 where nane =' lockscreen . lockedoutpernanent ly' ; 
update secure set ualue=0 where nane=' lockscreen . lockedoutpernanent ly' ; 
sqlite3 settings.db 
.quit 
exit 


3. Exit and reboot the device. 

4. The Android device should be unlocked. If not, attempt to remove gesture . key 
as explained earlier. 


Checking for the modified recovery mode and 
adb connection 

In Android, recovery refers to the dedicated partition where the recovery console is present. 
The two main functions of recovery are to delete all user data and install updates. For 
instance, when you factory reset your phone, recovery boots up and deletes all the data. 
Similarly, when updates are to be installed on the phone, it is done in recovery mode. There 
are many enthusiastic Android users who install custom ROM through a modified recovery 
module. This modified recovery module is mainly used to make the process of installing 
custom ROM easy. Recovery mode can be accessed in different ways depending on the 
manufacturer of the device, which is easily available on the Internet. Usually, this is done 
by holding different keys together such as the volume button and power button. Once in 
recovery mode, connect the device to the workstation and try to access the adb connection. 
If the device has a recovery mode which is not modified, the examiner may not be able to 
access the adb connection. The modified recovery versions of the device present the user 
with different options and can be easily noticed as shown in the following screenshot: 
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Flashing a new recovery partition 

There are mechanisms available to flash the recovery partition of an Android device with a 
modified image. The Fastboot utility would facilitate this process. Fastboot is a diagnostic 
protocol that comes with the SDK package, used primarily to modify the flash file system 
through a USB connection from a host computer. For this, you need to start the device in 
boot loader mode, in which only the most basic hardware initialization is performed. Once 
the protocol is enabled on the device, it will accept a specific set of commands that are sent 
to it via the USB cable using a command line. Flashing or rewriting a partition with a binary 
image stored on the computer is one such command that is allowed. Once the recovery is 
flashed, boot the device in recovery mode, mount the /data and /system partitions, and 
use adb to remove the gesture . key file. Reboot the phone and you should be able to 
bypass the screen lock. However, this works only if the device bootloader is unlocked. Also, 
flashing permanently alters the device. Instead of flashing, you could use the fastboot 
boot command to boot to a recovery image temporarily to delete the key file without 
permanently changing the recovery partition. 


Using automated tools 

There are several automated solutions available in the market for unlocking Android 
devices. Commercial tools such as Cellebrite and XRY are capable of bypassing the screen 
locks, but most of them require USB debugging to be enabled. We will now examine how to 
unlock an Android device using the UFED user lock code recovery tool. Also, this tool only 
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works on those devices that support USB OTG. This process also requires a UFED camera. 
Cable No. 500-Bypass lock, and Cable No. 501-Bypass lock. Once the tool is installed on the 
workstation, follow these steps to unlock an Android device: 

1. Run the tool on the work station and press 1 , as shown in the following 
screenshot: 


UFED User Lock Code Recouery Tool 

Disclaimer: All actions are subject to the full responsibility of the user, and 
Cellebrite is not liable for any damage to the deuice. 

Follow the instructions to recouer the lock code. 

Before you begin, check your computer's power options to make sure it won't go 
into sleep mode. The process could take from a few minutes up to 21 hours. Vou 
can still use the computer during this time. 


What type of deuice is it? 

[1] Android 

[2] iOS (Apple) 

[0] Exit 


UFED user lock code recovery tool 

2. Now, connect side A of Cable No. 500-Bypasslock to a USB port of the 
workstation. Also connect side B of Cable No. 500-Bypasslock to Cable No. 501- 
OTG, and then connect the other end to the device. 

3. Once connected, the tool prompts you to select the recovery profile. Select 1 
(Manually select the recovery profile). 
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Hou would you like to select the eecoueey profile? 

11 I Mrtcnirt I I y select the recouery profile. 

12 1 Use e wl/eeil Co )>elp you choose. 

(ill Fx I » 


4. Now, select the lock type used on the device and the recovery profile and 
proceed by following the instructions on the screen. 

5. After this, make sure that the keypad appears on the device screen and that it's 
ready to accept the PIN code. 

6. Close any message windows that may appear. Press 1 and hit Enter. Now make 
five incorrect login attempts by entering random input, and click on Forgot 
pattern at the bottom of the device. 

7. Follow the instructions on the screen, wait for the camera window to open, and 
then click on the camera window. 

8. Use the cursor to select any non-empty area on the device's screen by placing the 
green square over it. For example, select any number on the screen. This is used 
by the tool to detect if the device is unlocked. Press Enter to start the process. 

9. The tool will try a number of combinations to unlock the device. Once unlocked, 
it would prompt you to end the process. 


Using Android Device Manager 

Most of the latest Android phones come with a service called Android Device Manager, 
which helps owners of a device to locate their lost phone. This service can also be used to 
unlock a device; however, this is possible only when you know the Google account 
credentials that are configured on the device. If you have access to the account credentials, 
then follow these steps to unlock the device: 

1. Visit http : / / google . com/ android/ devicemanager on your workstation. 

2. Sign in using the Google account that is configured on the device. 

3. Select the device you need to unlock and click on Lock, as shown in the following 
screenshot: 
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Android Device Manager 

4. Enter a temporary password and click on Lock again. 

5. Once it's successful, enter the temporary password on the device to unlock it. 

It can be done without knowing the credentials of the computer where the login is saved 
(that is, the suspect's PC). Similarly, if you are dealing with a Samsung device, you can also 
try Samsung's FindMyMobile service, which enables you to set a temporary password to 
unlock the device. 


Smudge attack 

In rare cases, a smudge attack may be used to deduce the password of a touchscreen mobile 
device. This attack relies on identifying the smudges left behind by the user's fingers. While 
this may present a bypass method, it must be said that a smudge attack is unlikely since 
most Android devices are touchscreen and smudges will also be present from using the 
device. However, it has been demonstrated that under proper lighting, the smudges that are 
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left behind can easily be detected as shown in the following screenshot. By analyzing the 
smudge marks, we can discern the pattern that is used to unlock the screen. This attack is 
more likely to work while discerning the pattern lock on the Android device. In some cases, 
PIN codes can also be recovered depending upon the cleanliness of the screen. So, during a 
forensic investigation, care should be taken when the device is first handled to make sure 
that the screen is not touched. 



Smudges visible on a device under proper lighting (source: https : / /WWW .USenix.org/legacy/ event S /woot 1 0 /t 

ech/ full_papers/Aviv.pdf) 


Using the Forgot Password/Forgot Pattern option 

If you know the username and password of the primary Gmail address that is configured 
on the device, you can change the PIN, password, or swipe on the device. After making a 
certain number of failed attempts to unlock the screen. Android provides an option named 
Forgot Pattern or Forgot Password, as shown in the following screenshot: 
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5BW 

3 Draw pattern to unlock 


4:59 PM 


Emergency call 


Forgot pattern? 


Forgot pattern option on an Android device 

Tap on that link and sign in using the Gmail username and password. This will allow you 
to create a new pattern lock or passcode for the device. 

O Note that this works only on devices running Android 4.4 or earlier. 

Bypassing Third-Party Lock Screen by booting 
into safe mode 

If the screen lock is a third-party app rather than the inbuilt lock, it can be bypassed by 
booting into safe mode and disabling it. To boot into safe mode on Android device 4.1 or 
later, long-press the power button until the power options menu appears. Then long-press 
the Power Off option and you'll be asked if you want to reboot your Android device into 
safe mode. Tap the OK button as shown in the following screenshot. 
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Reboot to safe mode 


Do you want to reboot into safe mode? This will disable all third 
party applications you have installed. They will be restored 
when you reboot again. 

Cancel OK 


Safe mode in Android 

Once you're in safe mode, you can disable the third-party lock screen app or uninstall it 
completely. After this, reboot the device and you should be able to access it without any 
lock screen. 


Secure USB debugging bypass using adb keys 

As mentioned earlier, while using USB debugging, if the Always allow from this computer 
option is checked, the device will not prompt for authorization in future. This is done by 
storing certain keys, namely adbkey and adbkey . pub, on the computer. Any attempt to 
connect to adb from an untrusted computer is denied. In this case, the adbkey and the 
adbkey . pub files can be pulled from the suspect's computer and copied to the investigators 
workstation. The device will then assume that it is communicating with a known, 
authorized computer. The adbkey and adbkey .pub files can be found at 
C : \Users\<username>\ . android on Windows machines. 


Secure USB debugging bypass in Android 4.4.2 

As explained in the earlier sections, the secure USB debugging feature introduced in 
Android 4.4.2 allows only authorized workstations to connect to the device. However, 
there's a bug in this feature as reported at https : //labs .mwrinfosecurity . com/ which 
allows bypassing the Secure USB debugging feature and connecting the device to any 
workstation. Here are the steps to follow to bypass Secure USB debugging on an Android 
4.2.2 device: 
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1. On an unlocked device, attempt to use adb and observe that an error message is 
shown by the device. 

2. Now, navigate to either the emergency dialer or the lock-screen camera and 
execute the following commands: 

$ adb kill-server 
$ adb shell 

3. Observe that the confirmation dialog is now triggered and the workstation can be 
authorized without unlocking the device. As shown in the following screenshot, 
the confirmation dialog box is displayed on the emergency dialer. 


m USB debu 


The computer's BSA key 
fingerprint is: 

04 1 D:8C 09 8F 00 82 04 E9 80:09 
-98:EC:F8:42:7E 

Always allow from this computer 


Cancel 


OK 


*~Z> 


Bypassing Secure USB debugging in Android 4.2.2 

4. Once connected to the device through adb, try to bypass the lock screen using 
following command: 

$ adb shell pm clear com. android . keyguard 
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Crashing the lock screen Ul in Android 5.x 

On devices running Android 5.0 to 5.1.1, the password lock screen (not pin or pattern lock) 
can be bypassed by crashing the screen UI. This can be accomplished by following these 
steps as explained at http : / /android, wonderhowto . com/: 

1. Click on the Emergency Call option on the lock screen and then enter any 
random input (for example, 10 asterisks) on the dialer screen. 

2. Double-tap the field to highlight the entered text, as shown in the following 
screenshot, and choose Copy. Now paste it into the same field. 



Crashing lock screen Ul 

3. Repeat this process of copying and pasting to add more characters until double- 
tapping the field no longer highlights the characters. 

4. Go back to the lock screen and open the camera shortcut. Now, pull down the 
notifications screen and tap the Settings icon. You will then be prompted to enter 
a password. 
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5. Long-press the input field and choose Paste and repeat this process several more 
times. After pasting enough characters into the field, the lock screen will crash 
and allow you to access the device. 


Other techniques 

All of the previously mentioned techniques and the commercial tools available prove to be 
useful to the forensic examiner trying to get access to the data on the Android devices. 
However, there could be situations where none of these techniques work. To obtain a 
complete physical image of the device, techniques such as chip-off and JTAG may be 
required when commercial and open source solutions fail. A short description of these 
techniques is mentioned here. 

While the chip-off technique removes the memory chip from a circuit and tries to read it, 
the JTAG technique involves probing the JTAG Test Access Ports (TAPs) and soldering 
connectors to the JTAG ports in order to read data from the device memory. The chip-off 
technique is more destructive because once the chip is removed from the device, it is 
difficult to restore the device back to its original functional state. Also, expertise is needed 
to carefully remove the chip from the device by desoldering the chip from the circuit board. 
The heat required to remove the chip can also damage or destroy the data stored on that 
chip. Hence, this technique should be looked upon only when the data is not retrievable by 
open source or commercial tools or the device is damaged beyond repair. When using the 
JTAG technique, JTAG ports help an examiner to access the memory chip to retrieve a 
physical image of the data without needing to remove the chip. To turn off the screen lock 
on a device, an examiner can identify where the lock code is stored in the physical memory 
dump, turn off the locking, and copy that data back to the device. Commercial tools, such as 
Cellebrite Physical Analyzer, can accept the . bin files from chip-off and JTAG acquisitions 
and crack the lock code for the examiner. Once the code is either manually removed or 
cracked, the examiner can analyze the device using normal techniques. 

O Both the chip-off and JTAG techniques require extensive research and 

experience to be attempted on a real device. A great resource for JTAG and 
chip-off on devices can be found at 

http : / / www .forensicswiki.org/wiki. 
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Gaining root access 

As a mobile device forensic examiner, it is essential to know everything that relates to 
twisting and tweaking the device. This would help you to understand the internal working 
of the device in detail and comprehend many issues that you may face during your 
investigation. Rooting Android phones has become a common phenomenon and you can 
expect to encounter rooted phones during forensic examinations. The examiner, where 
applicable, may also need to root the device in order to acquire data for the forensic 
examination. Hence, it's important to know the ins and outs of rooted devices and how they 
are different from the other phones. The following sections cover information about 
Android rooting and other related concepts. 


What is rooting? 

The default administrative account in Unix-like operating systems is called "root". So, in 
Linux, the root user has the power to start/stop any system service, edit/delete any file, 
change the privileges of other users, and so on. We have already learned that Android uses 
the Linux kernel, and hence, most of the concepts present in Linux are applicable to 
Android as well. However, most of the Android phones do not let you log in as a root user 
by default. 

Rooting an Android phone is all about gaining access on the device to 
perform actions that are not normally allowed on the device. 

Manufacturers want the devices to function in a certain manner for normal 
users. Rooting a device may void a warranty since root opens the system 
to vulnerabilities and provides the user with superuser capabilities. 

Imagine a malicious application having access to an entire Android system with root access. 
Remember that in Android, each application is treated as a separate user and issues a UID. 
Thus, the applications have access to limited resources and the concept of application 
isolation is enforced. Essentially, rooting an Android device allows superuser capabilities 
and provides open access to the Android device. 



Rooting an Android device 

Even though the hardware manufacturers try to put enough restrictions to restrict access to 
the root, hackers have always found different ways to get access to the root. The process of 
rooting varies depending on the underlying device manufacturer. But rooting any device 
usually involves exploiting a security bug in the device's firmware and then copying the su 
(superuser) binary to a location in the current process's path (/system/xbin/su) and 
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granting it executable permissions with the chmod command. 

For the sake of simplicity, imagine that an Android device has three to four partitions, 
which run programs not entirely related to Android (Android being one among them). 

The boot loader is present in the first partition and is the first program that runs when the 
phone is powered on. The primary job of this boot loader is to boot other partitions and 
load the Android partition, commonly referred to as ROM by default. To see the boot loader 
menu, a specific key combination is required such as holding the power button and 
pressing the volume up button. This menu provides options for you to boot into other 
partitions, such as the recovery partition. 

The recovery partition deals with installing upgrades to the phone, which are written 
directly to the Android ROM partition. This is the mode that you see when you install any 
official update on the device. Device manufacturers make sure that only official updates are 
installed through the recovery partition. Thus, bypassing this restriction would allow you to 
install/flash any unlocked Android ROM. Modified recovery programs are those that not 
only allow an easier rooting process but also provide various options that are not seen in 
the normal recovery mode. The following screenshot shows the normal recovery mode: 


Android system recovery <3e> 

Volume up/down to move highlight: 
power button to select. 

reboot system now 
apply update from ADB 
update/recover from SD card 
wipe data/factory reset 

wipe cache partition 


Normal Android system recovery mode 

The following screenshot shows the modified recovery mode: 
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ClockyorkMod Recovery v4.0.0.4 

- reboot systen noy 

- apply update froM sdcard 

- yipe data/factory reset 

- yipe cache partition 

- install zip froM sdcard 

- backup and restore 

- nounts and storage 

- advanced 

- power off 


The modified recovery mode 

The most commonly-used recovery program in the Android world is the Clockwork 
recovery, also called ClockworkMod. Hence, most of the rooting methods begin by flashing 
a modified recovery to the recovery partition. After that, you can issue an update, which 
can root the device. However, you don't need to perform all the actions manually as 
software is available for most of the models, which can root your phone with a single click. 

Rooting a device has both advantages and disadvantages associated with it. 

The following are the advantages of rooting: 

• Rooting allows modification of the software on the device to the deepest level. 

For example, you can overclock or underclock the device's CPU. 

• It allows restrictions imposed on the device by carriers, manufacturers, and so on, 
to be bypassed. 

• For extreme customization, new customized ROMs can be downloaded and 
installed. 

The following are the disadvantages of rooting: 

• Rooting a device must be done with extreme care as errors may result in 
irreparable damage to the software on the phone, turning the device into a 
useless brick. 

• Rooting might void the warranty of a device. 
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• Rooting results in increased exposure to malware and other attacks. Malware 
with access to the entire Android system can create havoc. 

Once the device is rooted, applications such as the Superuser app are available to provide 
and deny root privileges. This app helps you to grant and manage superuser rights on the 
device, as shown in the following screenshot: 



Superuser Request 

Root Explorer is requesting Superuser access. 

Warning: If you did not initiate this action, or if you 
do not understand this request, it's generally a 
good idea to deny it. 

Tap for more info 

Deny Allow 

Remember 


Application requesting root access 


Root access - adb shell 

A normal Android phone does not allow you to access certain directories and files on the 
device. For example, try to access the /data /data folder on an Android device, which is 
not rooted. You will see the following message: 
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C : \android -sdk\platform- tools >adb. exe shell 
shell@android : / $ cd /data/data 
shell@android : /data/data $ Is 
opendir failed. Permission denied 
255 | shell@android : /data/data $ 


On a rooted phone, you can run the adb shell as a root by issuing the following command: 

C : \android-sdk\platform-tools>adb . exe root 
restarting adbd as root 


C : \android-sdk\platform-tools>adb . exe shell 

root@android : / # cd /data/data 

root@android: /data/data # Is 

android . googleSearch . googleSearchWidget 

com. android .MtpApplication 

com. android . Preconfig 

com. android . apps .tag 

com. android . backupconf irm 

com. android . bluetooth 

com. android . browser 


Thus, rooting a phone enables you to access folders and data, which are otherwise not 
accessible. Also, note that # symbolizes root or superuser access, while $ reflects a normal 
user, as shown in the preceding command lines. 


Summary 

A proper forensic workstation setup is required prior to conducting investigations on an 
Android device. Using open source methods to acquire and analyze Android devices 
requires the installation of specific software on the forensic workstation. If the method of 
forensic acquisition requires the Android device to be unlocked, the examiner needs to 
determine the best method to gain access to the device. Various screen lock bypass 
techniques explained in this chapter help an examiner to bypass the passcode under 
different circumstances. Depending on the forensic acquisition method and scope of the 
investigation, rooting the device should provide complete access to the files present on the 
device. 
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Now that the basic concepts of gaining access to an Android device have been covered, we 
will cover acquisition techniques and describe how the data is being pulled using each 
method in Chapter 9, Android Data Extraction Techniques. 
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11 

Android App Analysis, Malware, 
and Reverse Engineering 


Third-party applications are commonly used by smartphone users. Android users 
download and install several apps from app stores, such as Google Play. During forensic 
investigations, it is often helpful to perform an analysis of these apps to retrieve valuable 
data and to detect any malware. For instance, a photo vault app might lock sensitive images 
present on the device. Hence, it would be of great significance to have the knowledge to 
identify the passcode for the photo vault app. Also, apps, such as Facebook, WhatsApp, 
Skype, and so on, are widely used these days, and they are often the source of valuable data 
that aids in cracking a case. Hence, it would be important to know what kind of data these 
apps store and the location of this data. While the data extraction and data recovery 
techniques discussed in earlier chapters provide access to valuable data, app analysis would 
help us gain information about the specifics of an application, such as preferences and 
permissions. In this chapter, we will cover the following topics: 

• Analyzing some of the most widely-used Android apps to retrieve valuable data 

• Techniques to reverse-engineer an Android application 

• Android malware 


Analyzing Android apps 

On Android, everything the user interacts with is an application. While some apps are 
preinstalled by the device manufacturer, others are downloaded and installed by the user. 
For example even routine functions, such as contacts, calls, SMS, and so on, are performed 
through their respective apps. Thus, Android app analysis is crucial during the course of an 
investigation. Several third-party apps, such as WhatsApp, Facebook, Skype, Chrome 
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browser, and so on, are used widely, and they handle a lot of valuable information. 
Depending on the type of application, most of these apps store sensitive information on the 
device's internal memory or SD card. Analyzing them may provide information about the 
location details of the user, his communication with others, and so on. Using the forensic 
techniques described earlier, it is possible to get access to the data stored by these 
applications. However, a forensic examiner needs to develop the necessary skills to convert 
the available data into useful data. This is achieved when you have a comprehensive 
understanding of how the application handles data. 

As discussed in the previous chapters, all applications store their data in the /data /data 
folder by default. Apps also store certain other data on the SD card if they want to by asking 
permission during the time of installation. Information about applications present on the 
device can be gathered by inspecting the contents of the /data /data folder, but this is not 
straightforward. Hence, as an alternative you can inspect the packages . list file present 
under /data/ system. This file contains information about all the apps along with their 
package names and data path, as shown in the following screenshot: 


C : \android-sdk\platform-tools>adb . exe shell 
root@android : / # cd /data/system 
root@android: /data/system # cat packages. list 

com. google. android. location 10021 0 /data/data/com. google. android. location 

com. android. defcontainer 10026 0 /data/data/com. android. def container 

com. sec. android. gallery3d 10092 0 /data/data/com. sec. android. gallery3d 

com. sec. android. fotaclient 10041 0 /data/data/com. sec. android. fotaclient 

com. monotype. android. font. helvneuelt 10052 0 /data/data/com. monotype. android. font, 

com. sec. android. motions. settings. panningtutorial 10067 0 /data/data/com. sec. andrcn 

com. f mm. dm 10128 0 /data/data/com. f mm. dm 

android. googleSearch.googleSearchWidget 10049 0 /data/data/android.googleSearch.gc 
com. android. providers. calendar 10087 0 /data/data/com. android. providers. calendar 
com. android. bluetooth 10083 0 /data/data/com. android. bluetooth 


Content of thepackages . list file 

We will now cover various third-party apps that are widely used and handle valuable data. 
The following apps are covered only to make the reader familiar with the kind of data that 
can be extracted and the possible locations where the data can be obtained. 


Facebook Android app analysis 

The FacebookAndroid app is one of the most widely used social networking applications. It 
stores the information under /data/data folder with the com. facebook . katana 
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package name. The following details provide an overview of the kind of information that 
can be gathered across various files: 

• Facebook Contacts: Information about the user's Facebook contacts can be 
retrieved by analyzing the contacts_db2 database, which is present under the 
following path: 

Path: / data /data /com . facebook . katana/databases/contacts_db2 

The contacts_db2 database (SQLite file) contains a table named contacts, 
which has most of the information, such as their first name, last name, display 
name, URL for display picture, and so on. 

• Facebook Notifications: Information about a user's notifications can be gathered 
by analyzing the notif ication_db database, which is present under the 
following path: 

Path: / data /data /com . facebook . kat ana /databases /not if ications_db 

The gql_notifi cat ions table present under the preceding path holds the 
information. The seen_state column confirms whether a notification has been 
seen or not. The updated column points to the time when the notification was 
updated. The gql_payload column contains the notification and the sender 
information. 

• Facebook Messages: A Facebook message conversation may be of crucial 
importance in several cases and can be viewed by analyzing the threads_db2 
database: 

Path: / data /data /com . facebook . kat ana /dat abase s/threads_db2 

• Videos from newsfeed: The /video-cache folder contains videos downloaded 
from the user's newsfeed. Note that these are not the videos posted by the user, 
but rather they are the videos that appeared on his newsfeed: 

Path: / dat a/ dat a /com . facebook . katana/ files /video-cache 

• Images from newsfeed: The /images folder contains various images that appear 
on the user's profile, such as the ones from his newsfeed, contact profile pictures, 
and so on. Several directories are present within this folder, and images may be 
stored in formats other than . jpg, such as . cnt: 

Path: / dat a /dat a /com . facebook . katana/ cache /images 
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• Newsfeed data: The newfeed_db database contains data shown to the user on 
his newsfeed. As shown in the following screenshot, analyzing this database 
would provide valuable information, such as when a particular story was loaded 
by the device (the fetched_at column), if a particular story was seen by the user 
(the seen_state column), where the corresponding files of a story are stored on 
the device (the cache_f ile_path column), and so on: 

Path: /data/data/com. facebook . katana/databases/newsfeed_db 


© SQLite Database Browser - C:/Users/Rohit/Desktop/dump/andy/fb/databases/newsfeed_db 
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The Facebook newsfeed. db file analyzed in SQLite browser 


WhatsApp Android app analysis 

WhatsApp is the most popular chat (audio and video) messaging service used by more than 
a billion people across the globe. It stores the information under 
/data/data folder with the package name com. whatsapp . The following is an 
overview of the important files that are of interest from a forensic perspective: 

• Users Profile pic: The user's profile picture is saved with the filename me . jpg 
and is present under the following path: 

Path: / data /data /com . whatsapp /me . jpg 

• Users Phone Number (associated with WhatsApp): The me file present under the 
main folder contains the phone number that is associated with the user's 
WhatsApp account. Note that this may or may not be the phone number that is 
associated with the SIM: 
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Path: /data/data/com. whatsapp/me 

• Contacts Profile pic: The /avatars directory has thumbnails of profile pictures 
of the user's contacts (who use WhatsApp): 

Path: / dat a/ dat a /com. what sapp/ files/ Avatars 

• Chat messages: All the message-related information including chats, sender 
details, and so on is present in the msgstore . db file, which is present in the 
following location: 

Path: /dat a /dat a /com . what sapp/ dat abases /msgstore . db 

• WhatsApp Files: Most of the files shared with WhatsApp, such as images, 
videos, audio messages, and so on, are stored on the SD card in the following 
location: 

Path: / sdcard/Whats App /Media 

Both sent and received files are stored separately here with their respective folder names. 


Skype Android app analysis 

Skype is an app that offers video chat and voice call services. The application's data is 
stored under the /data/data folder with the package name com. skype . raider. The 
following are important artifacts that can be extracted by analyzing the Skype app: 

• Username and IP address: The shared, xml file present under the following 
path contains information about the username and the last IP address that 
connected to Skype: 

Path: / dat a/ dat a /com . skype .raider/files/shared. xml 

• Profile pic: The user's profile picture is present in the /thumbnails directory 
whose path is as follows: 

Path: / dat a/ dat a /com . skype .raider/ files/ <username>/thumbnails/ 

• Call logs: Information about call logs made from Skype is available in 
the main . db file. Analyzing this file gives us a lot of information: 

Path: / dat a/ dat a /com . skype .raider/ files/ <username>/main . db/ 


[ 296 ] 


Android App Analysis, Malware, arid Reverse Engineering 


For example, the duration table provides information about call duration, 
the start_time stamp field gives the start time of a call, and 
the creation_timestamp field indicates when the call is initiated (this includes 
unanswered calls). The type column indicated whether the call was incoming 
(value= 1) or outgoing (value= 2). 

• Chat Messages: The messages table present in the main . db file contains all the 
chat messages. The author and f rom_dispname columns provide information 
about who wrote the message. The timestamp column shows the date/time of 
the message. The body_xml column contains the content of the message. 

Path: / dat a/ dat a /com . skype .raider/ files/ <username>/main . db/ 

• Files transferred: The Transfers table contains information about transferred 
files, such as the filename, the size of the file, and their location on the device, and 
so on: 

Path: / dat a/ dat a /com . skype .raider/ files/ <username>/main . db/ 

• Group chats: The ChatMembers table shows a list of users who are present in a 
particular chat. The adder column shows the user who initiated the conversation: 

Path: / dat a/ dat a /com . skype .raider/ files/ <username>/main . db/ 


Gmail Android app analysis 

Gmail is a widely-used e-mail service offered by Google. The application data is saved 
under the /dat a /dat a folder with the package name com. google . android, gm. The 
following are important artifacts that can be extracted by analyzing the Gmail app: 

• Account Details: The XML files present under /shared_pref s confirm the e- 
mail account details. Details of other accounts, which are linked to the current e- 
mail, can be identified from the Gmail . xml file: 

Path: /dat a/ data/ com .google . android . gm/ cache/ <username>@gmail . com 

• Attachments: Attachments that are recently used in both sending and receiving 
mails are saved to the /cache directory. This is valuable because it gives access 
to items deleted from the mail too. The following is the exact path for this folder: 

Path: /dat a/ data/ com .google . android . gm/ cache/ <username>@gmail . com 
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List of attachments present under Gmail's cache directory 

• E-mail Subject: The subject of this e-mail can be recovered by analyzing 
the conversations table present in the 

mailstore . <username>@gmail . com db file. 

Path: 

/ data/ data /com. google . android . gm/ databases /mail store . <username> 
@gmail . com. db 

• Search History: Any text searches that were made within the app are stored in 
the suggestions . db file present at the following location: 

Path: /data /data /com .google . android . gm/dat abases /suggest ions . db 


Google Chrome Android app analysis 

Google Chrome is the default web browser in Nexus and many other devices, and it is used 
widely to browse the Internet. The application data is present under the /data /data folder 
with the package name com. android, chrome. The following are important artifacts that 
can be extracted by analyzing the Gmail app: 

• Profile pic: The profile pic of the user is stored with the filename Google Profile 
Picture . png in the following location: 

Path: /dat a/ data/ com . android . chrome/ app_chrome /Default/ Google 
Profile Picture. png 
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• Bookmarks: The Bookmarks file contains information about all the bookmarks 
synced with the account. Details, such as the site name, URL, and the time when 
it's bookmarked, can be gathered by analyzing this file: 

Path: /dat a/ data/ com . android . chrome/ app_chrome /Default/ Bookmarks 

• Browsing History: The History . db file contains the user's web history stored in 
the various tables. For example, as shown in the following screenshot, 

the keyword_search_terms table contains information about the searches that 
were made using the Chrome browser: 
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Google Chrome browsing history 

The segments table contains a list of sites visited by the user (but not all the sites). 
It's interesting to note that Chrome stores the data belonging to not just the device 
but the account in general. In other words, information about sites visited from 
other devices using the same account is also stored on the device. For example, 
the urls table contains the browsing history for a Google account across several 
devices: 

Path: /dat a/ data/ com . android . chrome/ app_chrome /Default /History 
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• Login Data: The Login Data database contains login information of different 
sites saved in the browser. The site URL, along with the username and password, 
is stored in the respective tables: 

Path: /dat a/ data/ com . android . chrome/ app_chrome /Default/ Login Data 

• Frequently visited sites: The Top Sites database contains a list of frequently 
visited sites: 

Path: /dat a/ data/ com . android . chrome/ app_chrome/Def ault /Top Sites 

• Other data: Other information, such as the phone numbers or e-mail addresses 
entered by the user during form fills across different sites, is stored in the Web 
Data database. Tables present within this database contain autofill data: 

Path: /dat a/ data/ com . android . chrome/ app_chrome/Def ault /Web Data 


Reverse engineering Android apps 

The examiner may need to deal with applications that stand as a barrier to accessing the 
required information. For instance, take the case of the gallery on a phone that is locked by 
an app locker application. In this case, in order to access the pictures and videos stored in 
the gallery, you first need to enter the passcode to the app locker. Hence, it would be 
interesting to know how the app locker app stores the password on the device. You might 
look into the SQLite database files. However, if they are encrypted, then it's hard to even 
predict that it's a password. Reverse engineering applications would be helpful in such 
cases where you want to better understand the application and how the application stores 
the data. 

To state it in simple terms, reverse engineering is the process of retrieving source code from 
an executable. Reverse engineering an Android app is done in order to understand the 
functioning of the app, data storage, the security mechanisms in place, and more. Before we 
proceed to learn how to reverse engineer an Android app, here is a quick recap of the 
Android apps: 

• All the applications that are installed on the Android device are written in the 
Java programming language. 

• When a Java program is compiled, we get bytecode. This is sent to a dex 
compiler, which converts it into a Dalvik bytecode. 

• Thus, the class files are converted to dex files using a dx tool. Android uses 
something called Dalvik virtual machine (DVM) to run its applications. 
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• JVM's bytecode consists of one or more class files depending on the number of 
Java files that are present in an application. Regardless, a Dalvik bytecode is 
composed of only one dex file. 

Thus, the dex files, XML files, and other resources that are required to run an application, 
are packaged into an Android package file (an APK file). These APK files are simply a 
collection of items within a ZIP file. Therefore, if you rename an APK extension file to . zip, 
then you will be able to see the contents of the file. However, before this, you need to get 
access to the APK file of the application that is installed on the phone. Here is how the APK 
file corresponding to an application can be accessed. 


Extracting an APK file from an Android device 

Apps that come preinstalled with the phone are stored in the /system/app directory. 
Third-party applications that are downloaded by the user are stored in the /data /app 
folder. The following method helps you gain access to the APK files on the device, and it 
works on both rooted and nonrooted devices: 

1. Identify the package name of the app by issuing the following command: 


C:\andnoid-sdk\platform-tools>adb.exe shell pm list packages 
package:android 

package : android . googleSearch . googleSearchWidget 

package: com. android .MtpApplication 

package : com . android . Preconf ig 

package: com. android . apps .tag 

package : com . android . backupconf irm 

package : com . android . bluetooth 

package : com . android . browser 

package : com . android . calendar 

package : com . android . certinstaller 

package : com . android . chrome 

package : com . android . clipboardsaveservice 

package : com . android . contacts 

package : com . android . def container 

package : com . android . email 

package : com . android . exchange 

package: com. android .facelock 


List of package names present on the device 
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As shown in the preceding command line output, the list of package names is 
displayed. Try to find a match between the app in question and the package 
name. Usually, the package names are very much related to the app names. 
Alternatively, you can use the Android Market or Google Play to identify the 
package name easily. The URL for an app in Google Play contains the package 
name, as shown in the following screenshot: 



Facebook App in Google Play Store 

2. Identify the full pathname of the APK file for the desired package by issuing the 
following command: 


fc:\android-sdk\platform-tools>adb.exe shell pm path com. android . chrome 
package : / data/app/com . android . chrome- 1 . apk 
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3. Pull the APK file from the Android device to the forensic workstation using the 
adb pull command: 


C:\android-sdk\platform-tools>adb.exe pull /data/app/com. android. chrome-1. apk C:\temp 
3706 KB/s (42168820 bytes in 11.110s) 


You can also use applications such as ES Explorer to get the APK file of an Android 
application. Now, let's analyze the contents of an APK file. An Android package is a 
container for an Android app's resources and executables. It's a zipped file that contains the 
following files: 

• AndroidManif est . xml: This contains information about the permissions and 
more 

• classes . dex: This is the class file converted to a dex file by the dex compiler 

• Res: The application's resources, such as the image files, sound files, and more, 
are present in this directory 

• Lib: This contains native libraries that the application may use 

• META-INF: This contains information about the application's signature and 
signed checksums for all the other files in the package. 

Once the APK file is obtained, you can proceed to reverse engineer the Android application. 


Steps to reverse engineer Android apps 

APK files can be reverse engineered in different ways to get the original code. The following 
is one method that uses the dex2jar and JD-GUI tools to gain access to the application code. 
For our example, we will examine the com . twitter . android-1 . apk file. The following 
are the steps to successfully reverse engineer the APK file: 

1. Rename the apk extension to zip to see the contents of the file. Rename 

the com . twitter . android-1 . apk file to 

twitter . android-1 . zip, and extract the contents of this file using any file 
archiver application. The following screenshot shows the files extracted from the 
original file twitter . android-1 . zip: 
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Name 

Date modified 

Type 

Size 
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File folder 


Jt com 
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File folder 


1. lib 

01-02-2014 15:32 

File folder 


META-INF 

01-02-2014 15:32 

File folder 


X res 

01-02-2014 15:32 

File folder 


AndroidManifest.xml 

07-01-2014 11:10 

XML Document 

43 KB 

| | classes.dex 

07-01-2014 11:10 

DEX File 

3,843 KB 

§ com.twitter.android-l.zip 

01-02-2014 15:31 

WinRAR ZIP archive 

11,877 KB | 

| , resources.arsc 

07-01-2014 11:10 

ARSC File 

2,282 KB 


Extracted files of an APK file 


2. The classes . dex file discussed in the earlier sections can be accessed after 
extracting the contents of the APK file. This dex file needs to be converted to a 
class file in Java. This can be done using the dex2jar tool. 

3. Download the dex2jar tool from https : //code . google . com/p/ dex2 jar/, 
drop the classes . dex file into the dex2jar tools directory, and issue the 
following command: 

C : \Users\Rohit\Desktop\Training\Android\dex2 jar-0 .0.9. 15>d2 j- dex2 jar . bat 
classes . dex 

dex2jar classes. dex -> classes-dex2 jar . jar 

4. When the preceding command is successfully run, it creates a new classes- 
dex2 jar . jar file in the same directory, as shown in the following screenshot: 
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Name 

Date modified 

Type 

Size 
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File folder 
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DEX File 

3,843 KB 
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Windows Batch File 

1KB 

d2j-apk-sign.sh 

05-06-2013 10:21 

SH File 
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Windows Batch File 

1 KB 
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05-06-2013 10:21 

SH File 

2 KB 

|5£] d2j-decrpyt-string.bat 

05-06-2013 10:21 

Windows Batch File 

1 KB 
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05-06-2013 10:21 

SH File 

2 KB 

E§>1 d2j-dex2jar.bat 

05-06-2013 10:21 

Windows Batch File 

1 KB 


The classes- de X 2 j a r . jar file created by the dex2jar tool 


5. To view the contents of this jar file, you can use a tool such as JD-GUI. As shown 
in the following screenshot, the files present in an Android application and the 
corresponding code can be seen: 



The JD-GUI tool 
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Once we get access to the code, it is easy to analyze how the application stores the values, 
permissions, and more information that may be helpful to bypass certain restrictions. When 
malware is found on a device, this method to decompile and analyze the application may 
prove useful, as it will show what is being accessed by the malware and provide clues to 
where the data is being sent. The following sections focus in detail on Android malware. 


Android malware 

As Android continues to increase its market share, so do attacks or malware targeted at 
Android users. Mobile malware is a broad term that refers to a piece of software that 
performs unintended actions and includes Trojans, spyware, adware, ransomware, and so 
on. According to Pulse Secure, 97 percent of mobile malware is focused at the Android 
operating system (http : //www. scmagazineuk . com/updated-97-of-malicious-mobi 
le-malware-targets-android/ article/422783/). As per statistics released by G- 
DATA software, almost 4,900 new Android samples are being discovered every day. The 
following is a sample screenshot that shows the rise of Android malware over the past few 
years (referenced from https : //public . gdatasoftware . com/Presse/Publikationen 
/Malware_Report s / G_DATA_Mobi leMWR_Ql_2 0 1 5_US . pdf): 



One of the primary reasons for this situation is that, unlike Apple's App Store, which is 
tightly controlled by the company, Google's Play Store is an open ecosystem without any 
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detailed upfront security reviews. Malware developers can easily move their apps to Play 
Store and thereby distribute their apps. Google now has a malware detecting software 
named Google Bouncer, which will automatically scan an uploaded app for malware but 
attackers have figured out several ways to remain undetected. Moreover, Android officially 
allows loading apps downloaded over the Internet (side-loading) unlike iOS, which does 
not allow unsigned apps. For example, as shown in the following screenshot, when the 
Unknown sources option is selected on an Android device, it allows the user to install apps 
that are downloaded from any site over internet: 


< Security 

http://findmymobile.samsung.com 
SIM CARD LOCK 

Set up SIM card lock 

PASSWORDS 

Make passwords visible 

Show password characters briefly as you 
type them 


DEVICE ADMINISTRATION 

Device administrators 

View or disable device administrators 



Sideloading option in Android 

The third-party app stores that host Android apps are known to be the hub of malware. 
This prompted Google to roll out the Verify apps feature starting from Android 4.2, which 
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scans apps locally on Android devices to look for malicious activities, such as SMS abuse. 
As shown in the following screenshot, the Verify apps feature may warn the user or in 
some cases may even block the installation. However, this is an opt-in service, so users can 
disable this feature if they choose to: 


▼al I3H 


1 1 54 


I Google Play Store 


A 


Installing this app may harm your 
device 

This app is potentially dangerous Installing it may 
harm your device, incur unwanted usage charges, or 
expose your personal information 

Google recommends that you do not install this app 

App name: 'Testing App" 

I understand that this app may be dangerous 


I Google Play Store 




Installation has been blocked 


This app Is dangerous It contains code that attempts 
to exploit a known vulnerability and could bypass 
Android's security protections 

To protect you. Google has blocked the installation of 
this app. 

App name "Super History Eraser* 


Verify apps feature in Android 

Once malware gets into a device, it can perform dangerous actions, some of which are 
listed, as follows: 

• Send and read your text messages 

• Steal sensitive data, such as pictures, videos, credit card numbers, and so on 

• Manipulate files or data present on the device 

• Send SMS to a premium-rated number 

• Infect your browser and steal any data typed into it 

• Change device settings 
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• Wipe the entire data present on the device 

• Lock the device until a ransom is paid 

• Display advertisements continuously 

Advanced malware is also capable of rooting the device and installing new apps. For 
example, the Android Mazar malware, discovered in Feb 2016, spreads via text messages 
and is capable of gaining administrator rights on phones, allowing it to wipe handsets, 
make calls, or read texts. 

A full list of Android malware families and their capabilities is available at 

http : / / forensics . spreitzenbarth . de/ android-malware/ for 

reference. 


How does malware spread? 

An Android device can be infected with malware in several different ways. The following 
are some of the possible ways: 

• Repackaging legitimate application: This is the most common method used by 
attackers. The attacker first downloads a legitimate application, disassembles it, 
then adds their malicious code, and reassembles the application. The new 
malicious application now functions exactly as the legitimate application does, 
but it also performs malicious activity in the background. These kind of 
applications are commonly found in the third-party Android app stores and are 
downloaded by several people. 

• Exploiting Android vulnerabilities: In this scenario, an attacker exploits the bugs 
or the vulnerabilities that are discovered in the Android platform to install his 
malicious application or to perform any unwanted actions. For example, installer 
hijacking, identified in 2015, has been exploited by attackers to replace an 
Android application with malware during installation. 

• Bluetooth and MMS propagation: Malware is also spread via Bluetooth and 
MMS. The victim receives the malware when the device is in discoverable mode, 
for example, when it can be seen by other Bluetooth-enabled devices. In the case 
of MMS, the malware is attached to the message just as computer viruses are 
send through e-mail attachments. However, in both these methods, the user has 
to agree at least once to run the file. 

• App downloading malicious update: In this case, the app originally installed 
does not contain any malicious code but a function present within the code will 
download malicious commands at runtime. This can be done via a stealthy 
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update or user update. For example, the Plankton malware uses stealthy updates 
that directly download a JAR file from a remote server and do not need any user 
permission. In the case of user updates, the user has to allow the app to 
download the new version of the app. 

• Remote Install: The attacker may compromise the credentials of the user's 
account on the device and thereby remotely install apps on the device. This 
generally happens in targeted scenarios and is less frequent compared to the 
other two methods just described. 


Identifying Android malware 

From a forensic perspective, it's important to identify the presence of any malware on the 
device prior to performing any analysis. This is because malware can alter the state of the 
device or contents on the device, thereby making the analysis or the results inconsistent. 
There are tools available in the market that can analyze the physical extraction to identify 
malware. For example, Cellebrite UFED Physical Analyzer has BitDefender's antimalware 
technology, which scans for malware. As shown in the following screenshot, once the 
physical image is loaded into the tool, the file can be scanned for malware. 



Scanning for malware in UFED Physical Analyzer 
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Once the scan starts, the BitDefender software tries to unpack the . apk files and looks for 
infected or malicious files. Hence, the process is automatic, and the tool points to the 
malicious apps, as shown in the following screenshot: 


2 Physical Analyzer 

File View Tools Python Plug-ins Report Help 

fcaf Ida §1/ 0 4 i & <£> 0 » 

Project Tree » 9 

^8 n 


Malware Scanner (331) 


_com.aijiaoyou. android. sipphone_1005_1.0.5. apk (Android.Trojan.DroidKungFu.A) 

% _com.electricsheep.master.paintpro_10_2.01.aplc (Android.Trojan.DDLightA) 

#; _com.lceji.unclear_l_l.0_BC6C20C79AED279B409C614A92E63BB9.apk (Android. Trojan. BaseBridge 
% _com.sansec_9_V1.0.09.apk (Android.Trojan.DroidKungFu.A) 

% 0DA3484A20C85C0489FEA8F53316B53C (Android.Trojan.Geinimi.B) 


Malware scanner results in UFED Physical Analyzer 

The tool simply points out that something malicious is present on the device. The forensic 
investigator has to then manually confirm whether this is a valid issue by analyzing the 
respective application. This is where the reverse engineering skills that were discussed in 
the previous sections need to be leveraged. Once the application is reverse engineered and 
code is obtained, it is recommended that you take a look at the AndroidManifest . xml file 
to find out the app permissions. This will be helpful to understand where the app stores the 
data, what resources it is trying to access, and so on. For example, a Flashlight application 
does not need read/write access to your SD card data or to make a call. 
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fuses-permission android : name* "android. permission. ACCESS_CGARSE_LOCAIIOH"> 

f/ uses -permission 

■fuses -permission android :name=*android. permission. ACCE55_FINE_L0CVII0H*> 

< /uses -pe rmiss ion> 

■cuses -permission android :name=*android. permission. ACCESS_KETWORK_STAIE*> 

</uses -permission 

•fuses -permission android: name="android. permission. ACCESS_WIFi_STAI£"> 

</uses -pe rmiss i on> 

fuses -permission android: name-"android. permission. CALL_F30NE"> 

</uses-permission> 

fuses -permission android: name- "android. permission. CAMERA “> 
f/uses -permission 

fuses -permission android:name»"android. permission. GET_ACCOCNTS’> 

</uses-permission> 

fuses -permission android :name*"andrcld. permission. IKTERHET"> 

f /uses-permission> 

fuses -permission android :name**android. permission. M«HA3E_ACC0CNTS*> 
f /uses- pe rmiss lon> 

fuses-permission android :name="android. permission. READ_CO!fTACTS"> 

f /uses -pe rmiss ion> 

fuses -permission andrcid:Bame="android. permission. R£AD_P3QNE_STAXE"> 

f /uses -permrssion> 

fuses-permission android :name="android. permission. tTSE_CREDEirriALS”> 

f /uses -permission> 

fuses-permission android: caise-'androld. permission. VT3RATE"> 

f/uses-pe rmiss ion> 

fuses-permission android: name* "android. pem ssion. WRITE_oi.il ldGS~> 

f /uses- pe rmiss ion> 

fuses -pe rmiss ion andr c id : name* " andro id . pe rmiss ion . WRITE_EXTERNAI_ST CRAGE ”> 

f /uses -pe rmiss ion> 


Permissions in the AndroidManifest . xml file 


It's also important to note that the tool may not identify a valid case if the details are 
obfuscated in the . apk file. Hence, as a forensic investigator it's important to develop the 
necessary skills to reverse engineer any suspicious apps and analyze the code to identify 
malicious behavior. In some investigations, the nature of the malware that is present on the 
device may also result in arriving at certain crucial conclusions, which may affect the 
outcome of a case. For example, consider an internal investigation in a corporation that 
involves sending abusive messages to other employees. Identifying malware on this device 
that sends. 
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Summary 

Android app analysis helps a forensic investigator to look for valuable data in 
relevant locations on the device. Reverse engineering Android apps is the process of 
retrieving source code from an APK file. Using certain tools, such as dex2jar. Android apps 
can be reverse engineered in order to understand the functionality of the app and data 
storage, identify malware, and more. Identifying malware present on the device is crucial as 
it may affect the outcome of the investigation. Tools such as UFED Physical Analyzer come 
with BitDefender software, which can automatically scan for malware. The next chapter 
covers performing forensics on Windows Mobile devices. 
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Windows Phone Forensics 


Windows phones are becoming more widely used, and they may be encountered during 
forensic investigations. These devices are the most affordable on the market, so 
understanding how to acquire, analyze, and decode data from Windows phones is 
important. Locating and interpreting digital evidence that is present on these devices 
requires a specialized knowledge of the Windows Phone operating system and may not 
always be possible. Commercial forensic and open source tools provide limited support to 
acquire user data from Windows devices. As Windows Phones do not occupy much of the 
mobile market space, most forensic practitioners are unfamiliar with the data formats, 
embedded databases used, and other artifacts that exist on the device. This chapter provides 
an overview of Windows Phone forensics, describing various methods of acquiring and 
examining data on Windows mobile devices. 

In this chapter, we will cover the following topics: 

• Windows Phone OS 

• Windows Phone Security 

• Jailbreaking Windows Phones 

• Forensic acquisition and analysis 


Windows Phone OS 

Windows Phone is a proprietary mobile operating system developed by Microsoft. It was 
launched as a successor to Windows Mobile, but it does not provide backward 
compatibility with the previous platform. Windows Phone was first launched in October 
2010 with Windows Phone 7. The version history of the Windows Phone operating system 
then continued with the release of Windows Phone 7.5, Windows Phone 7.8, Windows 
Phone 8.1, and Windows Phone 10. Although the market share of this operating system is 
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limited, there is certainly a case for optimism based on the following reasons: 

• The computer operating system market is still dominated by Windows. This 
gives Windows Phone OS greater flexibility to provide users with a computer 
environment that they are familiar with. 

• Windows Phones are the most affordable smartphone on the market. 

The following sections will provide more detail about Windows Phone 8 and 8.1, its 
features, and its underlying security model. We believe that data is stored similarly on 
Windows Phone 7 and Windows Phone 10, so the methods defined in the following sections 
should work on both operating systems. At the time of writing, Windows Phone 10 was just 
being introduced as an option for upgrade on Windows 8 and 8.1 devices and was available 
for purchase on new Windows Phones. 

Unlike Android and iOS devices, Windows Phone comes with a new interface, which uses 
so-called tiles for apps instead of icons, as shown in the following figure. These tiles can be 
designed and updated by the user. 



The Windows Phone home screen 
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Similarly to other mobile platforms, Windows Phone allows for the installation of third- 
party apps. These apps can be downloaded from the Windows Phone Marketplace, which is 
managed by Microsoft. When comparing the amount of apps available for iOS and Android 
devices, the Windows Phone pales in comparison. However, applications are available and 
the examiner should expect to see them on Windows Phone devices. 

The Windows Phone introduced new features, making it similar to other smartphones 
when compared to Windows Mobile: 

• Cortana: This is the personal assistant for the device. It was introduced in 
Windows 8.1 and is still present on Windows 10 devices. Cortana aids the user by 
fielding questions using Bing, setting reminders, sending texts, and essentially 
using all the functionality to provide the user with a better and easier experience. 
Everything that Cortana does leaves a trace on the device. 

• Wallet: This stores credit card accounts, boarding passes, tickets, coupons, and 
more. 

• Geofence and advanced location settings: These provide the user with 
additional protection as the phone can detect when it is out of a trusted zone and 
may lock itself. 

• Additional features: These are features such as live Tiles, enhanced colors, quiet 
hours, and more. 

Other common applications associated with the Windows Phone include OneDrive, 
(formerly SkyDrive), OneNote, and Office 365 Synchronization. OneDrive provides the user 
with access to all of their documents and files from any device. OneNote is essentially the 
same, but it acts as a notebook or diary. Office 365 provides the user with constant access to 
their e-mail, calendar, contacts, and more across multiple devices. 

The introduction of data synchronization across multiple devices makes our job as forensic 
examiners difficult. It is our job to determine how the evidence was placed on the device. Is 
it possible to definitively state how an artifact was placed on a device? To be honest, this 
depends. Nobody wants to hear this response, but a lot of factors must be considered. What 
is the app? What OS is running on the device? What is the artifact? For example, let's 
consider SkyDrive. If the device contains documents from SkyDrive, the original author 
should be contained within the metadata. This, together with examining whether or not the 
content was shared to the device, may provide a glimpse into how the artifact was created. 
However, when examining a calendar entry when Office 365 is in place, it may be 
impossible to state if the user created the entry on their phone, PC, or laptop. The 
synchronization is instantaneous and status flags stating where the artifact was created do 
not always exist. If this artifact is indeed the "smoking gun" of the investigation, you need 
to apply your skills to uncover other artifacts that support your findings. Digging deeper 
into the data is required. 
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Security model 

The security model of Windows Phone is designed to make sure that the user data present 
on the device is safe and secure. The following sections provide a brief explanation of the 
concepts on which Windows Phone security is built. 


Windows chambers 

The Windows Phone is heavily built on the principles of least privilege and isolation. This 
has been consistent since the inception of Windows Phone 7. To achieve this, Windows 
Phone introduced the concept of chambers. Each chamber has an isolation boundary where 
processes can run. Depending on the security policy of a specific chamber, a process 
running in this chamber has the privilege of accessing the OS resources and capabilities 
(https : //www. msec.be/mobcom/ws2013/presentations/david_hernie .pdf). There 
are four types of security chambers. The following is a brief description of each one of them: 

• Trusted Computing Base (TCB): This processes here have unrestricted access to 
most of the Windows Phone resources. This chamber has the privileges to modify 
policies and enforce the security model. The kernel runs in this chamber. 

• Elevated Rights Chamber (ERC): This chamber is less privileged than the TCB 
chamber. It has the privileges to access all resources except the security policy. 
This chamber is mainly used for services and user-mode drivers, which provide 
functionality intended for use by other applications on the phone. 

• Standard Rights Chamber (SRC): This is the default chamber for preinstalled 
applications, such as Microsoft Outlook Mobile 2010. 

• Least Privileged Chamber (LPC): This is the default chamber for all the 
applications that are downloaded and installed through the Marketplace Hub 
(which is also known as the Windows Phone Marketplace). 


Encryption 

Windows Phone 8 introduced Bitlocker technology to encrypt all user data that is stored on 
the device via AES 128-bit encryption. The user can simply flip the switch to enable this 
feature and all of their data residing on the internal storage of the device is encrypted. In 
addition, the user can encrypt their SD card, assuming the phone has one, and set a 
password or PIN on their device. Should all of these locks and encryption be enabled, 
accessing the data on this device may be impossible, unless the password is recovered. 
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Capability-based model 

Capabilities are defined as the resources on the phone (camera, location information, 
microphone, and more) associated with security, privacy, and cost. The LPC has a minimal 
set of access rights by default. However, this can be expanded by requesting more 
capabilities during the installation. Capabilities are granted during the app installation and 
cannot be modified or elevated during runtime. For this reason, it is difficult to side-load 
applications or force custom bootcode to the device to gain forensic access, as it is normally 
rejected prior to boot up. 

To install an app on a Windows phone, you need to sign in to Marketplace with a Windows 
Live ID. During installation, apps are required to ask the user for permission before using 
certain capabilities, an example of which is shown in the following screenshot: 


Microsoft account 


Let this app access your info? 

OneNote Service WP8 Sample needs your 
permission to: 

Create new pages in OneNote 

You can change these application permissions 
at any time in your account settings. 


Yes 


© 2014 Microsoft 


Windows app requesting user permissions (https : //i-msdn . sec . s-msft . com/dynimg/ IC7 5 2 3 7 0 .png) 

This is similar to the permission model in Android. This gives the user the freedom to learn 
about all the capabilities that an application has before installing the application. The list of 
all capabilities is included in the WMAppManif est . xml application manifest file, which can 
be accessed through Visual Studio or other methods that are defined at https : //msdn.mic 
rosoft . com/ en-us/ library /windows/ apps/ ff769509 (v=vs . 105 ) . aspx. 
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App sandboxing 

Apps in Windows Phone run in a sandboxed environment. This means every application on 
Windows Phone runs in its own chamber. Applications are isolated from each other and 
cannot access the data of other applications. If any app needs to save information to the 
device, it can do so using the isolated storage, which is restricted from access by other 
applications. Also, the third-party applications installed on Windows Phone cannot run in 
the background; that is, when the user switches to a different application, the previously- 
used application is shut down (although the application state is preserved). This ensures 
that the application cannot perform activities, such as communicating over the Internet 
when the user is not using the application. These restrictions also make the Windows Phone 
less susceptible to malware, but never assume that any device is safe. It is just more 
challenging for malware to function on these devices. 


The Windows Phone file system 

The Windows Phone file system is more or less similar to the file systems used in Windows 
7, Windows 8, or Windows 10. From the root directory, one can reach different files and 
folders that are available on this device. From a forensic perspective, the following are some 
of the folders that can yield valuable data. All the listed directories are located in the root 
directory: 


• Application Data: This directory contains data of preinstalled apps on the phone, 
such as Outlook, Maps, and Internet Explorer. 

• Applications: This directory contains the apps installed by the user. The isolated 
storage, which is allocated or used by each app, is also located in this folder. 

• My Documents: This directory holds different Office documents, such as Word, 
Excel, or PowerPoint. The directory also includes configuration files and 
multimedia files, such as music or videos. 

• Windows: This directory contains files that are related to the Windows Phone 
operating system. 

The acquisition method used here will determine the amount of file system access that the 
examiner has to the device. For example, a physical image may provide access to several 
partitions that can be recovered from the data dump. We are looking at a Windows Phone 8 
device that contained 28 partitions in the following screenshot. Partitions 27 and 28 contain 
the relevant data. 
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© These screenshots were provided by Cindy Murphy, who co-authored 

Windows Phone 8 Forensic Artifacts, which can be found at http : / /www . sa 
ns . org/ reading-room/whitepapers/ forensics/windows-phone-8 
-f orensic-artif act s-357 87. 



Windows Phone 8 system partition 

The partition in the preceding screenshot. Partition 27, contained the system data from the 
Windows Phone. As in all Windows investigation, the system data contains artifacts 
relevant to investigations. 

While most artifacts will exist in the Data Partition, it is always best 
practice to capture and analyze both when possible. 


In this example. Partition 28 contained the User or Data Partition. Depending on the device, 
the partition numbers may vary. In the example provided by Cindy Murphy, the Data 
Partition is shown in the following figure as Partition 28. Here, the SMS, e-mail, application 
data, contacts, call logs, and Internet history were recovered using custom scripts and 
methods to extract the relevant data. These methods will be discussed later in this chapter: 
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EE)~J^ Partition 28 5. -i 
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Windows Phone 8 data partition 

Windows Phone also maintains the Windows registry, a database that stores environment 
variables on the operating system. The Windows registry is basically a directory that stores 
settings and options for the Microsoft operating system. The Windows Phone is no 
different. When examining a Windows Phone, an examiner will expect to see the 
NTUSER.dat, SAM, SYSTEM, SOFTWARE, SECURITY, and DEFAULT hives. While these hives 
may be unique to the phone, they can be examined just like traditional Windows registry 
hives. 

A detailed case investigation is included in the paper by Cindy Murphy. This involves a 
criminal case of a Home Invasion and Sexual Assault and details the efforts of great minds 
in the forensic community to uncover artifacts that assisted in closing the investigation. 
Sometimes, the mobile device is the most important artifact pertaining to the case. For more 
information, refer to http: / /www. sans . org/reading-room/whitepapers/forensics/ 
windows-phone-8-f orensic-artif acts-35787. 


Data acquisition 

Acquiring data from a Windows Phone is challenging for forensic examiners, as the 
Physical, File System, and Logical methods that were defined in previous chapters are not 
greatly supported. In addition to this, the phone may need to be at a specific battery charge 
state (%) in order for the commercial tool to recognize and acquire the device. This is often 
one of the most difficult steps in acquiring Windows Phones. You will hear stories of 
seasoned examiners using the flashlight app on the phone to drain the battery. Yes, actually 
using a feature of a phone just to get the device into a state where forensic methods will 
allow access. 
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One of the most common techniques implemented by commercial tools attempting data 
acquisition is to install an application or agent on the device, which enables a two way 
communication for commands to be sent to the device in order to extract data. This could 
result in certain changes on the device; nevertheless, this is still forensically sound if the 
examiner follows standard protocols and has tested the validity of the tool being used. 

These protocols include proper testing to ensure no user data is changed (and if changed, 
documenting what occurred), validation of the method on a test device, and documenting 
all steps taken during the acquisition process. For this acquisition method to work, the app 
needs to be installed with the privileges of the Standard Rights Chamber. This may require 
the examiner to copy the manufacturer's DLLs, which have higher privileges, into the user 
app. This allows the app to access methods and resources that are usually limited to native 
apps. In addition to this, the device must be unlocked or these methods may not work. 

Most examiners rely on forensic tools and methods to acquire mobile devices. Again, these 
practices are not as supported for Windows Phones. Keep in mind that, to deploy and run 
an app on Windows Phone, both the phone and the developer must be registered and 
unlocked by Microsoft. This restriction can be bypassed by unlocking the device using tools, 
such as Chevron WP for Windows Phone 7 devices, and a public jailbreak for Windows 
Phone 8 to 10 devices. More information on these jailbreaks can be found at http : //winph 
onehub . org/ jailbreak/. These jailbreaks basically allow the bypassing of the 
Marketplace procedure and allow you to sideload (run unsigned applications without the 
restrictions listed) an unpublished application. All jailbreaks must be tested in order to 
ensure they will not change user data, brick the device, or even wipe the data partition. The 
latest jailbreaks for the Windows Phone 8, 8.1, and 10 devices leverage vulnerabilities that 
are quickly patched by Microsoft. At the time of writing this book, a successful jailbreak for 
Windows 8.1 was not accessible to the author, but we are not saying it is impossible and 
that one does not exist. When attempting to jailbreak our test device, we were only 
accessing a Chinese method that did not support our device. This is shown in the following 
screenshot. If the red X had not identified an unsupported device, the jailbreak could have 
occurred successfully. Refer to http : / / 4mobiles . net /windows-phone/tutorials-win 
dows -phone/ j ailbreak-any-windows-phone-running-windows-88-1/. 
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Windows Phone jailbreak 


Sideloading using ChevronWP7 

This method will only work on Windows Phone 7 devices. Make sure that your model is 
supported for this jailbreak. As explained earlier, in order to install the app that provides 
access to the file system of the phone, we first need to unlock the device (similar to 
jailbreaking on iOS devices). This method will only work on a Windows Phone that is not 
locked with a passcode. This can be done using the Chevron WP7 tool by performing the 
following steps: 

1. Download the ChevronWP7 . exe and ChevronWP7 . cer files. Note that these files 
are often removed and are not always available on the same site. One location 
that currently has the files available for download 

is http : / / www . 4 shared . com/ f ile/HQGmwIRx/ ChevronWP7 . htm?locale=en. 

2. Install ChevronWP7 . cer file on the Windows Phone. Note that the methods for 
the installation of Chevron WP7 may require techniques that are not standard to 
forensic practices. Thus, all methods must be tested on a sample Windows Phone 
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to ensure user data is not lost in the process of attempting to extract the data. One 
method to install Chevron WP7 includes sending it to an e-mail and accessing it. 
This method should be used as a last resort when all other acquisition methods 
fail. 

3. Connect the phone to your computer and make sure that the device is not 
passcode-locked. If the device is locked and the password is known, enter the 
password only when prompted by the computer. Do not guess the password on 
the Windows Phone as multiple incorrect guesses may wipe the user data. 

4. Run the ChevronWP7 . exe file, check both the boxes shown in the following 
screenshot, and click on Unlock. This enables the developer unlock on the device 
and also enables you to install any third-party app without a Marketplace 
developer account: 



The ChevronWP7 tool 

To execute native code in a user app, the Windows . Phone . interopService DLL is used. 
This DLL provides the RegisterComDLL method, which can import native manufacturer 
DLLs. Hence, by including this DLL in a user app, it is possible to execute native code 
within the app and get access to the entire file system of the phone, including the isolated 
storage. 
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Commercial forensic tool acquisition methods 

There are a few commercial tools available that offer support for the acquisition of 
Windows Phone devices. Cellebrite UFED offers support to acquire Windows Phone 
devices using the Logical, File System, and Physical methods. At the time of writing this 
book, the devices listed in the following table are supported for acquisition and analysis: 


Vendor 

Model 

Vendor 

Model 

Alcatel 

505 5W Fierce XL (Windows) 

Nokia GSM 

Lumia 630 (RM-976) 

Dell 

V02S Venue Pro 

Nokia GSM 

Lumia 630 (RM-977) 

HTC 

0P6B180 One M8 for Windows 

Nokia GSM 

Lumia 630 (RM-978) 

HTC 

PM23200 SX 

Nokia GSM 

Lumia 635 (RM-974) 

HTC 

PM23220 SX 

Nokia GSM 

Lumia 635 (RM-975) 

HTC 

PM23300 Sx 

Nokia GSM 

Lumia 710 (RM-803) 

HTC 

PM 23 320 8X 

Nokia GSM 

Lumia 710.1 (RM-809) 

HTC 

MSM7x30 Omega 

Nokia GSM 

Lumia 720 (RM-855) 

HTC 

PM59100 8S 

Nokia GSM 

Lumia 720 (RM-885) 

HTC 

7 Mozart 

Nokia GSM 

Lumia 735 (RM-10 38) 

HTC 

CllOe Radar 

Nokia GSM 

Lumia 800 (RM-801) 

HTC 

X310e Titan 

Nokia GSM 

Lumia 810 (RM-878) 

HTC 

C625a 8X 

Nokia GSM 

Lumia 820 (RM-825) 

HTC 

A620 m8s 

Nokia GSM 

Lumia 820.1 (RM-825) 

HTC 

0106110 Radar 4G 

Nokia GSM 

Lumia 820.2 (RM-824) 

HTC 

MWP6885 7 Pro 

Nokia GSM 

Lumia 830 (RM-983) 

HTC 

MWP6 985 Trophy 

Nokia GSM 

Lumia 830 (RM-984) 

HTC 

G990L8X 

Nokia GSM 

Lumia 830 (RM-985) 

HTC 

T7575 Arrive 

Nokia GSM 

Lumia 900 (RM^23) 

HTC 

T8686 7Tropby 

Nokia GSM 

Lumia 909 (RM-875) 

HTC 

T8788 Sun-o und 

Nokia GSM 

Lumia 909.1 (RM-875) 

HTC 

9292 Desire HD 7 

Nokia GSM 

Lumia 920 (RM-820) 

HTC 

T9295 HD7S 

Nokia GSM 

Lumia 920.2 (RM-S 21) 

HTC 

HT C6 99 5LVW One M8 

Nokia GSM 

Lumia 925 (RM-892) 

HTC 

PI86100 Titan II 

Nokia GSM 

Lumia 925 (RM-893) 

HTC 

P0881008XT 

Nokia GSM 

Lumia 930 (RM-1045) 

HTC 

PC93 100 Arrive 

Nokia GSM 

Lumia 1020 (RM-877) 

T-Mobile 

HD7 

Nokia GSM 

Lumia 1520 (RM-9 38) 

Huawei 

W1-U00 Ascend 

Nokia GSM 

Lumia 1520 (RM-940) 

Huawei 

W2-U00 Ascend W2 

Nokia GSM 

Lumia 1520.1 (RM-937) 

Huawei 

H883GW1 

Nokia GSM 

Lumia 1320 (RM-994) 

LGCDM4 

VW820 

Nokia GSM 

Lumia 1320.1(RM-995) 

LG GSM 

E900Optimus 7 

Prestige 

Mult iPhone PSP8500DUO 

LG GSM 

C900 Quantum 

SFR 

Windows Phone Internet 7 by SFR 

Microsoft 

Lumia 735 (RM-1041) 

Samsung CDMA 

SM-W750V ATIV SE 

Microsoft 

Lumia 535 (RM- 1089) 

SamsungCDMA 

SPH-I800ATIVS Neo 

Microsoft 

Lumia 550 (RM-1128) 

Samsur^CDMA 

SCH-R860U ATIV Odyssey 

Microsoft 

Lumia 640 XL (RM-10G3) 

Samsur^CDMA 

SCH-1930 ATIV Odyssey 

Microsoft 

Lumia 435 (RM-1071) 

SamsurgGSM 

SGH-T 899 M ATIV S 

Microsoft 

Lumia 640 (RM-1072) 

SamsurgGSM 

SGH-i917 Focus 

Microsoft 

Lumia 640 (RM-1073) 

Samsung GSM 

GT-S7530 

Microsoft 

Lumia 950 XL (RM-1085) 

Samsung GSM 

GT-18350 Omnia W/GT-18700 Omnia 7 

Microsoft 

Lumia 950 (RM-1105) 

Samsung GSM 

GT-18750 ATIV S 

NokiaCDMA 

Lumia 822 (RM-845) 

Smart Phones/P DAs 

Wndows Phone 7 

Nokia CDMA 

Lumia 928 (RM-860) 

Smart Phones/ PDAs 

Windows Phone 8 

NokiaCDMA 

Luma 635 (RM- 1078) 

ZTE CDMA 

MWP3505US Render 

Nokia GSM 

Lumia 505 (RM-923) 

ZTEGSM 

Tania 

Nokia GSM 

Lumia 510 (RM-889) 

ZTE GSM 

Internet 7 

Nokia GSM 

Lumia 520.2 (RM-9 15) 

HTC 

PI06110 Radar 4G 

Nokia GSM 

Lumia 520 (RM-914) 

HTC 

HD7 

Nokia GSM 

Lumia 521 (RM-917) 

HTC 

PI39100Titan 

Nokia GSM 

Lumia 525 (RM-998) 

T-Mobile 

PI06110 Radar 4G 

Nokia GSM 

Luma 530 (RM-1017) 

Nokia CDMA 

610C 

Nokia GSM 

Lumia 530 (RM-1018) 

Nokia CDMA 

Lumia 929 (RM-927) 

Nokia GSM 

Lumia 530 (RM-1019) 

Nokia GSM 

Famous 

Nokia GSM 

Lumia 610 (RM-835) 

Samsung GSM 

SGH-1187 ATIV S Neo 

Nokia GSM 

Lumia 620 (RM-846) 

Samsung GSM 

SGH-i677 Focus Flash 

Nokia GSM 

Lumia 625 (RM-941) 

Samsung GSM 

SGH-i937 Focus S 
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Some of these acquisition methods are more robust, obtain a full physical dump of the data, 
and can bypass some lock codes on specific devices. However, some device support 
includes simply extracting contacts and pictures from the device. It is important for the 
examiner to realize that specific steps must be taken as directed by the tool. Acquiring these 
devices is not easy and often the examiner will find that the tool will not be successful. 

When the tool seems to fail, attempt to acquire the device using the Smartphone/PDA 
option offered in UFED. To do this, follow these steps: 

1. Launch UFED4PC and select Mobile Device. 

2. Select Browse Manually. 

3. Select Smartphones. 

4. Select the Windows device that you are attempting to acquire, as shown in the 
following image: 



UFED4PC extraction generic method options 


5. Try all the methods that are offered, starting with Physical, File System, and 
Logical (in that order, where possible.) 
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3* 

^jj Logical Extraction 


§+ 

m File System Extraction 


UFED4PC extraction options 


6. Follow all the remaining steps and try all offered acquisition methods until 
successful. 

Cellebrite may alert you that the acquisition is not successful for several reasons. When this 
occurs, try every option to ensure you have exhausted the commercial options available. An 
example of an acquisition attempt in UFED4PC is shown as follows: 

1. Launch UFED4PC. 

2. Select your Make and Model for the device. 

3. Select the Physical, File System, or Logical acquisition method (offerings will 
vary depending on the device model). 

In this example, only the Logical acquisition was supported. Two methods are available. 
The first option uses a cable and the second uses Bluetooth. In this example, a special UFED 
cable is required. I selected the UFED cable first, as Bluetooth requires that additional 
changes be made to the phone during pairing: 



UFED4PC Logical extraction options 
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When attempting to acquire the device with cable A with black tip T-100, only multimedia 
files were accessible. In this situation, acquire these items: 


^P Contacts 

Q Pictures 

0 SMS 

Ql Audio/Music 

0 MMS 

^ Videos 

^P Email 

Q Ringtones 

£ IM 

^ Call Logs 

^P Calendar 

^P Browsing Data 

Apps data 

User Dictionary 


UFED4PC extraction options (cable) 

Then, attempt the same acquisition, but select Bluetooth. Follow the instructions to pair the 
device to the forensic workstation: 


0 Contacts 

^ Pictures 

0 SMS 

Audio/ Music 

^ MMS 

^ V ideos 

^P Email 

Ringtones 

^ IM 

^P Call Logs 

^P Calendar 

^P Browsing Data 

^P Apps data 

^P User Dictionary 



UFED4PC extraction options (Bluetooth) 
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With this acquisition method, we were able to obtain contacts. Note that there was not a 
method offered to obtain SMS, MMS, Email, IM, Calendar, Call Logs, Apps data, and 
others. It is suggested you repeat the Generic methods listed in the previous screenshot 
using the Smartphone option in UFED4PC. 

Error messages are more common during the acquisition of Windows Phone devices when 
compared to other phones. Unfortunately, the state of the device and how it was used can 
affect the data that can be extracted. Note that in the following screenshot the phone cannot 
be acquired because the device does not contain photos. In this example, the user saved all 
of the pictures on the device to the SD card. Unfortunately, this is a reality and a common 
error. At this point, attempt another acquisition method. The following screenshot shows 
common error messages that may be reported by the tool. Here, we are looking at an 
extraction error from UFED4PC: 


Extraction Error 

Cannot read phone memory (34) 

GT-I8750 ATIV S: 

To allow phone connection: 

• Battery should be fully charged. 

• Phone must contain pictures. 

1. Power on the phone and wait until it's fully booted. 

2. Disable phone lock settings if enabled. 

3. Connect the phone device. 

4. Press Continue. 


UFED4PC extraction error message 

Oxygen Detective provides both acquisition and analysis support for Windows Phone 
devices. As previously mentioned, several extraction methods will be offered, and errors 
are expected, as these devices are difficult to acquire. At the time of writing this book. 
Oxygen Detective offers support for the following devices: 
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Manufacturer 

Models 

Acer 

Liquid M220 Plus 

Attview 

Impera i, Impera i8, Lmpera S, WP i, WP S 

Archos 

40 Cesium 

BLU 

Wm HD, Wm |r LTE (X130Q), Win |r 

Celkon 

Win 400 

Cherry Mobile 

Alpha Luxe, Alpha Neon, Alpha Style, 
Alpha View 

Fty 

Era Windows (IQ400W) 

FPT 

Win 

freetel 

NINJA 

Highscreen 

Winjoy, WinWin 

Hisense 

MIKA6 

HTC 

8X LTE (HTC6990LVW), 8XT, 

Windows Phone 8S, Windows Phone 8X 

Huawei 

Ascend Wl, Ascend W2 

iBall 

Andi4L Pulse 

Kazan 

Thunder 340W, Thunder 450W, 

Thunder 450WL 

K-Touch 

5703A, 5705A 

Lava 

Iris Winl 

LG 

Lancet (VW820) 

Micromax 

Canvas Win W092, Canvas Win W121 

Microsoft 

Lumia 1030, Lurnia 1330, Lumia 430, 

Lumia 435 DTV, Lumia 435, Lumia 535, 
Lumia 540, Lumia 640 XL, Lumia 640, 
Lumia 830 Gold, Lumia 930 Gold, 

Windows Phone Cloud, 

Windows Phone Cloud, 

Windows Phone JTAG 

Mouse Computer 

MADOSMA Q501 

Nokia 

Lumia 1020 (909), Lumia 1020, Lumia 1320, 
Lumia 1320.1, Lumia 1320.3, Lumia 1520, 
Lumia 1520.1, Lumia 1520.3, Lumia 520, 
Lumia 520.2, Lumia 520T, Lumia 521, 

Lumia 525, Lumia 525.2, Lumia 526, 

Lumia 530, Lumia 532, Lumia 535, 

Lumia 620, Lumia 625, Lumia 630, 

Lumia 635, Lumia 636, Lumia 638, 

Lumia 720, Lumia 720T, Lumia 730, 

Lumia 735, Lumia 810, Lumia 820, 

Lumia 822, Lumia 825, Lumia 830, 

Lumia 920, Lumia 920.2, Lumia 920T, 

Lumia 925, Lumia 925.2, Lumia 925T, 

Lumia 928, Lumia 930, Lumia Icon (929), 
Lumia Icon, MultiPhone 8400 DUO, 

Win Q900s 

Prestigio 

MultiPhone 8500 DUO 

QMobile Pakistan 

Wl 

Ramos 

07 

Samsung 

ATTV Odyssey SCH I930, ATTVS Neo, 
AITVS, AtivSE 

Windows Phone 

Generic Windows Phone 8 

XOLO 

Win Q1000, Win Q900s 

Yezz 

Billy 4.0, Billy 4.7 
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To acquire a supported device, perform the following steps: 

1. Launch Oxygen Forensic Detective. 

2. Select Connect Device. 

3. Select your preferred connection method. Manual device selection is preferred, as 
it provides the examiner with the most control over the extraction: 


Oxygen Forensic® Extractor 

Oxygen Forensic® Extractor helps to connect and extract data from device. 



Connection Mode 

§ Auto device connection 

Auto mode connects the first device detected on PC. 


-flt' Manual device selection 


y 


Manual selection mode allows to choose connection type and device model 
from the list. 


Physical data acquisition 


# Help 


MTK Android dump LG Android dump 

Samsung Android dump (via custom forensic recovery) 

No rooting is required. Lock screen is bypassed. 

The method may take a bit more time than physical dump via rooting. 

Disable screen lock 

Screen lock disabling for LG devices based on Android OS. To disable the lock it 
is required to have LG United Mobile Driver for LG devices. 

Screen lock disabling is performed via regular USB cable. 

Cancel 


The Oxygen Detective Extraction wizard 

4. Next, select the model that you wish to acquire. If the model is not available, 
simply attempt to acquire the device as a generic device. First try the cable 
method, followed by the Bluetooth method if needed: 
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Oxygen Detective Device Selection options 

5. Continue following the prompts to name the case file and select the artifacts to 
extract. Be prepared to troubleshoot errors. 

6. Open the extraction and begin analysis. 


Extracting data without the use of commercial 
tools 

On an unlocked device, it may be possible to run an app that can extract the user data 
present in the phone. This device may have to be jailbroken for this to work. Several apps 
that do this are available, and they depend on the version of Windows running on the 
phone and the version on your forensic PC. Two apps will be covered in this section. The 
first is TouchXperience and the second is Windows Phone app for Desktop. 
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The TouchXperience app, which comes with the Windows Mobile Device Manager 
(WPDM), can be used for this purpose. WPDM is the management software for Windows 
Phone 7. The TouchXperience client app extracts data, such as the file system, from the 
mobile device, and WPDM retrieves this data and converts it into a human-readable 
graphical format. The following are the steps that will help a forensic examiner extract user 
data present on an unlocked Windows Phone device: 

1. Download Windows Phone SDK 7.1 and the Zune software on the forensic 
workstation and install it 

(http: //www.microsoft . com/en-us/download/details . aspx?id=27570). 

2. Download the Windows Phone Device Manager on the workstation, and 
launch WPDeviceManager . exe 

(http: //touchxperience . com/windows-phone-device-manager/). 

3. Connect the device to the workstation, and it should be detected automatically. If 
it is not detected, make sure that a passcode is not set on the device. If it is, this 
process may fail if the passcode is unknown. 

4. Windows Phone Device Manager will automatically install the TouchXperience 
app when the phone is connected for the first time. Make sure that you set what 
the software is allowed to do on the device (that is, make sure not to change the 
user data, not update date/time settings, or anything else that will modify the 
user data). Make sure to document that TouchXperience was installed in order to 
extract data from the Windows Phone, as standard forensic methods provide 
little support for these devices. 

5. Thereafter, the following screen is presented, providing access to a vast amount 
of files that are present on the device: 


[ 333 ] 


Windows Phone Forensics 



Windows Phone Device Manager 

The home screen displays information about the model of the phone, OS version, and more. 
Click on Manage applications to see the information about installed apps on the device, as 
shown in the next screenshot. WPDM also provides other functionality, such as media 
management, synchronization of files and folders, and more. From a forensic point of view, 
the File Explorer is the most interesting part of this software. It provides read, write, and 
executable access to most of the files that are present on the Windows Phone 7 device: 
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Name 

Publisher 

Installed On 

Si 2 e 

Veraion 

Installed Applications 









3 Touch Xplorer 

Julian Schapman 

28/02/2011 

664.91 KB 

1000 

J TouchXperience 

Julian Schapman 

28/02/2011 

2.42 MB 

1020 

y Bluetooth 

Julian Schapman 

28/02/2011 

587.02 KB 

1000 

■O. Config avancee 

Julian Schapman 

28/02/2011 

1.31 MB 

1.1.01 

fditeur de registre 

Julien Schapman 

28/02/2011 

1.29 MB 

1100 

Purchased Applications 





HU Config Connexion 

HTC Coiporation 


913,10 KB 

1.000 

m Con vertisseur 

HTC Corporation 


1,82 MB 

1.0.00 

HTC Hub 

HTC Coiporation 


18.04 MB 

10 0.0 


Windows Phone Device Manager - The Manage Applications screen 

Using this acquisition technique, you can access two types of data: system data and 
application data. System data is mainly the data that is required to run the phone, and 
application data is the data created and used by different applications that are installed on 
the device. While system data may not contain data relevant to your investigation, 
application data is very valuable. Regardless, all data should be acquired from any 
smartphone, as the examination must be complete and capture all the data contained on the 
device when possible. The following sections discuss the steps to be followed to extract 
application data from a Windows Phone device. The application data will contain the bulk 
of the user-created data, and it will provide the most value to your investigation. 

Windows Phone app for Desktop works like the app that we just defined, but it supports 
the Windows Phone 8 device. Note that both the phone and the SD card can be accessed. 
The user relies on this app to transfer and sync files similar to how iPhone users rely on 
iTunes. Examiners rely on this app as a method to extract user artifacts when all other 
options are exhausted. When attempting to acquire data from the SD card, please refer to 
the methods discussed later in this chapter. 


[ 335 ] 


Windows Phone Forensics 


Windows Phone app for desktop 



Heather's Windows Phone 

SAMSUNG GT-I8750 S> 100 % 


music photos videos podcasts 

Name Time Artist 

It's lonely in here... 


Capacity 14.7 GB Phone ’ 


■ system i photos 

2.1 GB 4.8 MB 


■ apps 
110.7 MB 


i other 
354.3 MB 


Settings I Help 

pc phone 

Search P 

Size SD card 


free 
1Z1 GB 


Windows Phone app for Desktop 

Other options for Windows 8.1 include the Windows Phone Appand Phone Companion 
App for Windows 10 devices. These apps provide the user with additional functionality 
and allow for the copying of files from the PC to the phone and or SD card. 


SD card data extraction methods 

Windows Phones may contain removable SD cards. These cards may be secured with a key 
that prevents the SD card from being removed and used or accessed via other devices 
(phones, cameras, computers, and more). This is different from the key that is created if the 
user encrypts the SD card. Brute force and dictionary attacks can be run on user-encrypted 
SD cards to attempt to access the data. When examining a Windows Phone, it is best to 
research the device to see whether SD card security will be a factor when acquiring data 
from the device. If so, simply follow the preceding steps and acquire the SD card data 
through the phone during forensic extraction; or refer to the following chart. 

For devices where the SD card can be removed, you have two scenarios to consider. If the 
device is on, should you acquire the phone and the SD card as is? If the device is off, should 
you remove the SD card and acquire the device using FTK Imager as discussed in Chapter 
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1 0, Android Data Analysis and Recovery ? The answer is: it depends. In forensics, we use this 
statement frequently, but it remains true. If you leave the device on, it must be isolated from 
the network to ensure that it is not remotely accessed and immediately acquired, or the 
battery will drain and, ultimately, the device may power down. If the device is off and you 
remove the SD card, you must ensure that the card remains tied to the device itself and is 
acquired both externally and internally to ensure all data is captured. In a normal situation, 
the following chart suggests recommended steps to handle SD cards that are found in 
Windows Phones: 


Windows Phone 8 
seized in 
investigation 


Windows Phone is 
powered on 


Acquire the device 
with the SD card 
inside the phone 


Remove the SD card 
and acquire with 
FTK Imager 


Windows Phone is 
powered off 




Remove the SD card 
and acquire using 
FTK Imager 




Place the SD card 
back into the phone 
and acquire both 
device and SD card 


Most commercial forensic tools will offer to extract data from SD cards. Often, the phone 
extraction will only be data residing on the SD card. This is often the case when there is no 
support for a specific Windows Phone. If the SD card is not recognized by the tool and the 
data is not extracted, it is likely that the SD card has been encrypted by the user, and the 
password for the device is different from the password for the SD card. When this occurs, 
try to crack the passcode and re-acquire the device. Note that cracking a passcode on an SD 
card may not always be possible, but it's worth a shot using brute-force and dictionary 
attacks as you would on a standard hard drive or external device. 
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When acquiring an SD that has been removed from a Windows Phone, FTK Imager is a free 
and reliable option to create a forensically sound image that can be examined in a variety of 
tools. To create an SD card image, follow these steps: 

1. Remove the SD card from the device and make sure to document all identifiers 
on the card and the phone to ensure that they are not permanently separated. 

2. Insert the SD card into a write blocker and insert this into your forensic 
workstation. 

3. Launch FTK Imager. 

4. Select File and then select Create Disk Image. 

5. Select Physical Drive: 



FTK Imager - creating a disk image 

6. Use the drop-down to select the correct device. (Hint: look at the make and size to 
ensure that you are acquiring the correct device.) 

7. Select Finish. 

8. Click on Add and select Image Type. For this example, . dd is going to be used as 
it is supported by most commercial and open source methods for analysis. 
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Create Image 


Image Source 

| \V\PHYSICALDRIVE1 


Image Destination(s) 



si FT 

Select Image Type 

Please Select the Destination Image Type 
<• Raw(dd) 
r SMART 

r eoi 
r AFF 


p" Verify images after they are cr< 
l~ Create directory listings of all fi 


Cancel 




Help 


FTK Imager - Selecting Image Type 

9. Enter the relevant case information and select Next. This can be skipped. 
10. Select the Image Destination. 



FTK Imager - Saving your image file 
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11. Select Finish and then select Start. It is recommended that you verify images 
after they are created. 

Once complete, your results will be displayed. We will cover analyzing the SD card data in 
the following sections. 

Key artifacts for examination 

No matter which method was used to acquire the data, the following key artifacts should be 
examined. 

Extracting SMS 

All the incoming and outgoing short messages (SMS) in Windows Phone 7 - 8.1 are stored 
in the file named store . vol, which is present under the \Application 
Data\Microsoft\Outlook\Stores\DeviceStore (Windows 7) and 
\APPDATA\Local\Unistore (Windows 8-8.1) directory. An example of Windows 7 
SMS is shown in the next screenshot. It is not possible to copy this file directly because this 
file is always in use. When this file is renamed (for example, to store . vol . txt 
or store . bkp), it automatically creates a copy of the file. Once the copy is made, this file 
can now be examined using a normal text editor. Take a look at the following screenshot: 



The Store . vol file in Windows Phone 
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Extracting e-mail 

Windows Phone devices use Outlook as their standard e-mail client. This can be used to 
synchronize with various e-mail services, such as Google, YahooMail, and more. Data that 
belongs to Outlook is currently stored in the \Application 

Data\Microsoft\Outlook\Stores\DeviceStore\data directory, as shown in the 
following screenshot: 



Windows Phone: extracting e-mail 


As shown in the next screenshot, there are different folders present that contain different 
data. For example, the 3 folder contains pictures of the user's contacts (e-mail receivers). 
This folder is being used as an example. This folder will not be consistently named folder 3 
across Windows Phone devices. Take a look at the following screenshot: 


i. Device Store 
Jt data 






"Tmrnmmrzn* 

I 13.77 Ko 

000003000000000301a8 dal 

! 22.10 Ko 

000005000000000301a8 dat 


100001000000000301a8dat 

26,68 Ko 

1 0000200000000030 1a8 dat 

1 0000500000000030 1aS dat 

300001000000000301a8dat 

30000200000000030 1a8 dat 

300004000000000301a8 dat 


0 

18 

19 

3 

a 

k b 
M c 
k d 
k • 
k * 
it s 
k h 
it ' 
k J 
it * 
it I 
it id 

k n 

it 0 


c**er DAT 
M0 Ko 


10.64 Ko 

100001000000000300H dat 

1 00002000000000 300H dat 

1 00005000000000 300H dat 

11.75 Ko 

300001 000000000 300R dat 

300002000000000300H dat 

4 21 Ko 

30000400000000030QR dat 


Windows Phone: folder 3 
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Although the files are present with the . dat extension, by renaming them to . jpg, we can 
view the pictures as shown in the following screenshot: 



Windows Phone: renaming data files to JPG files 

Similarly, folder 4 contains information about e-mail messages. By renaming the files 
to HTML, we can view the content of the e-mail messages. Again, each folder should be 
examined for relevance as they may contain e-mail messages, attachments, contacts, and 
more. 

When an app meant to access Windows Phone devices just does not seem to sync to your 
device, the phone can be connected to the forensic workstation, and it can be manually 
explored by the examiner. This should be the last method used, as a Windows computer is 
known to reach out and 'talk' to the phone, so data will appear in a non-write protected 
format and can be changed: 




Phone 

SD card 


- . B 1 

12.0 GB free of 14.6 GB 

927 MB free of 956 MB 

Status 




Windows Phone: Windows Explorer view 
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Note that both the device and the SD card are accessible. Use caution when exploring in this 
view as changes can be made to the device. Additionally, files in use by the device will be 
locked, but the directory will be present: 



'▼| k “ Phone ► Data ► Users ► Default ► 


Organize " 

■a 4 Favorites 

APPDATA 

It Downloads 

1 BL. File folder 

i> Recent Places 

ft. Local Disk (Q 

K NTUSER 

DAT File 

i PFUV 

96.0 KB 

■ Desktop 

NTUSER.DAT{88C417D2-8632-llE2 

-AD66-D4AE5283184Q.TM 

a " i Libraries 

BLF File 

j Documents 

NTUSER.DAT{88C4140E-8632-llE2 

J 1 . Music 

-AD66-D4AE5283184C}.TM 

-> Pictures 

BLF File 

^ Videos 

NTUSER.DAT{88C41907-8632-llE2 

-AD66-D4AE5283184Q.TM 

BLF File 

> A Computer 



Windows Phone: Windows Explorer view of files 


System and Data files are viewable via this exploration method. Note that the Windows 
Phone is similar to a PC and contains a NTUSER . DAT file that can be parsed for user activity 
and other artifacts: 
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Appln stall 

File folder 

DPP 

File folder 

MMOS 

File folder 

PROGFiAMDATA 

File folder 


System Volume Information 

File folder 



USERS 
File folder 



Data 

File folder 

EFIESP 

File folder 

PROGRAM FILES 

File folder 

PROGRAMS 

File folder 

test 

File folder 

Windows 

File folder 


Windows Phone: Windows Explorer view of directories 

While some contents locked by the device may be inaccessible, it provides a glimpse as to 
what exists on the device. This is a great method to validate the forensic extraction to ensure 
no data was missed. 


Extracting application data 

The Applications folder contains all the applications that are installed on the phone. Each 
application has its own directory, which is identified with a unique application ID. Inside 
the application ID folder, there are other important folders, such 
as Cookies, History, IsolatedStore, and more. Most of the crucial information is 
usually present in the IsolatedStore folder. For example, as shown in the next 
screenshot, the IsolatedStore folder in Facebook contains the following data: 
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AppNobficat)ons_149 1.'-» »> 
Feed_MostRecent_149 • ■ ■■ ■ 
Feed_UserWall_14913» « » 
Friends 

Group_1359( • " - 

Group_1518(— - - 

HomePage 
Notes 

Notifications 

Pagelist_5438' 

PageList_7706t 
PageList_1005 ■ 
PageList_1038 t -»'i 
PageList_l039; « 
PageList_1095* * *» •• 
PageList_1131** » • 
PageList_1170 • 

PageUst_1346 H • 
PageList_1455. - * • ■ 


j PageList_10000 184 

LPageLis^lOOOOlS? • ■-* 

1 Pagelist_10000204 » 

I PageList_10000226 « u 

|_ j PageList_10000234 » 1 1 
[_ j Pagelist_1000024€ ’ » 
L_ j PageList_1000027C' m 
PageList_ 10000 298 
L _ i PageList_1000039? - 
L Pagelist_100004 15 

I PageLtst_10000435» 

PageList_ 1000044 j u • 

1 PageList_1000051?' * * 
PhotoCollage_149 1M * ' 
PhotosForUser_149 * * 
Requests 

UmfiedThreadListJnbox 

UmfiedThreadList_Other 

1 _ UserGroups_1491 >* • 


Contents of the I S 0 1 a t e ds t O r e folder 

By analyzing these folders, a forensic analyst can gather a lot of information that could aid 
the investigation. The following are some of the findings from our Facebook app analysis 
example: 

• The userid, settings file in the following screenshot contains the user's profile 
name and a link to the user's profile and profile picture. 

• All the pictures that are used by the Facebook app are stored in the Images folder 
present in the IsolatedStore directory. To view these images, change the 
extension of the files to JPG. 

• The DataCache . userlD folder contains most of the information about the 
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Facebook account. By parsing this folder, information about friends, friend 
requests, messages, and more can be obtained. This is straightforward as all the 
files, once extracted, can be manually examined for their relevance to the 
investigation. 


k 

A 


DataCache. 14913* 

Dossier 

05/01/2013 08:38:52 

Images 

iV*— ^ r 

05/01/2013 08:38:58 


k 

k 


DataCache.5472 ■ 

IlMMiiir 

11/01/2013 11:09:38 

Shared 

Dossier 

05/01/2013 00:42:38 


Application Settings 

Rchier 
1.30 Ko 


1491jn • settings 

==] Visual Studio Settmgs-Designer 
1.27 Ko 



5472 settings 

Visual Studio Settmgs-Designer 
0.21 Ko 


-k app settings 

= Visual Studio Settmgs-Designer 
_ 0.03 Ko 


Fatal EmorLogtxt 

"*| Ftchier TXT 
I 21.99 Ko 


ImageMetadata 

"* Ftchier 
_ 1.49 Ko 


TheDataCache . User ID folder of the Facebook app 

Another location that contains application data is the 

\Public\Pictures\SavedPictures directory. 

Similarly, by examining the Internet Explorer app, a forensic examiner can gather 
information about the sites visited by the user. All this data can be found under the 

Application Data\Microsoft\Internet Explorer or 

\ APPDATA\ INTERNETEXPLORERE \ INETCACHE directories. By analyzing the Maps 
application, information about the user location and other details can be obtained. The call 
logs can be recovered from \APPDATA\Local\UserData\Phone on most devices. Keep in 
mind that the location may vary depending on the OS and the Windows device. However, 
the directory containing the data (phone, store . vol, and so on) remains the same. A great 
source to conduct forensics on a Windows Phone device can be found 

at http : / /cheeky 4 n6monkey . blogspot . com/ 2014/ 0 6 /monkey ing-around-with-win 
dows-phone-80 . html. 
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Summary 

Acquiring data from Windows Phone devices is challenging as they are secure and 
commercial forensic tools and open source methods do not provide easy solutions for 
forensic examiners. Multiple tools, chip-off, JTAG, and the methods defined in this book are 
some of the methods that provide access to user data on Windows Phone devices. Often, 
you will find that Windows Phone devices require multiple extraction methods to acquire 
accessible data. The biggest challenge is getting access to the device to acquire the data. 
Once the data is available, all the extracted information can be analyzed by the examiner. 
UFED Physical Analyzer and Oxygen Detective both accept JTAG and chip-off extractions 
for analysis. 

Again, the device must not contain a passcode. It must be unlocked (jailbroken or rooted) to 
use non-commercial methods, and it may be modified by the examiner in order to extract 
the data using the methods defined in this chapter. While some may challenge us and say 
that these methods are not common in forensic practices, they must realize that these 
methods may be the only way to obtain user data from Windows Phone devices. In the next 
chapter, we will cover third-party applications, that while challenging, are more often 
supported by commercial and open source methods. 
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Third-party applications have taken the smartphone community by storm. Most 
smartphone owners have more than one app on their device that they rely on to chat, game, 
get directions, or share pictures. According to http : //www . statista . com/statistics/ 
27 6623/ number-of-apps-available-in-leading-app-stores/, there are almost 4 
million apps existing worldwide for the various smartphones. Apple App Store offers 
approximately 1.5 million apps, Google Play offers 1.6 million, Amazon offers 400,000 apps, 
and Windows offers 340,000. This number is expected to grow exponentially through 2017. 

The goal of this chapter is to introduce you the various applications seen on Android, iOS 
devices, and Windows Phones. Each application will vary due to versions and devices, but 
their underlying structures are similar. We will look at how the data is stored and why 
preference files are important to your investigation. 

We will cover the following topics in detail in this chapter: 

• Different third-party applications 

• How applications are stored on iOS devices 

• How applications are stored on Android devices 

• Windows Phone 8 application storage 

• How to use both commercial and open source solutions to parse application data 


Parsing Third-Party Application Files 


Third-party application overview 

Third-party applications are an integral part of mobile device investigations. Often, the key 
artifacts seem to exist within an application. This requires the examiner to understand 
where application data is stored on the device, how application data is saved for this 
platform, and which tool best helps uncover the evidence. Manual parsing is often a key 
factor when examining third-party applications on any smartphone. While some 
commercial tools, such as Magnet IEF, are known for application parsing support, no tool is 
perfect and it's virtually impossible for tools to keep up with the frequent updates that are 
released for each application. Most often, you will realize that the commercial tools parse 
the most popular applications on the market. For example, when Facebook purchased 
WhatsApp, Cellebrite, IEF, and Oxygen Forensics started supporting this application. 
Facebook is extremely popular, but data isn't always extracted or parsed, due to security 
features that are built into the app. This is where all apps differ. Our best advice is to test, 
test, and test! You can download an app, populate data, and examine the results to see how 
your view of the evidence compares to your actual evidence. This practice will enable you 
to understand how updates change the artifacts, how evidence locations have changed, and 
how to manually extract artifacts that your tools are missing. Additionally, reverse- 
engineering an app and analyzing its code will help us identify where the data is stored and 
how it is stored. 

Most applications do not require a data plan for use. They can fully function off a WiFi 
network, which means that apps function when a person travels to a region in which their 
device will not work. For example, when I travel, I rely on Skype, Viber, and WhatsApp to 
call and text family and friends. All that is required is that my smartphone is connected to 
WiFi. 

We have already addressed some third-party application extraction and analysis tips in this 
book. In addition to this, we discussed the files that need to be examined to understand and 
analyze application data in Chapter 6, iOS Data Analysis and Recovery, Chapter 1 0, 
Android Data Analysis and Recovery, Chapter 1 1 , Android App Analysis, Malware, and Reverse 
Engineering, and Chapter 12 , Windows Phone Forensics. This chapter will dive deeper into 
the applications and relevant files and prepare the examiner for the analysis of these 
artifacts. Each application has a purpose. Most tools provide support for the most popular 
application in each category. The rest is up to you. A glimpse of applications as presented 
by Oxygen Detective is shown in the following screenshot. As expected, these are not all of 
the applications that are present on the device; rather, these are just the ones that the tool 
knows how to parse: 
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Applications (14) 

B 294 

Applications 


Social Networks 

Google + 1 Pinterest 5 


Twitter 2810 


Messengers 

Hangouts 1 Tango 101 Zello 212 



Web Browsers 

Gooole Chrome 023 

Opera Mini Web Browser 1 


Productivity (Business) 

Dropbox 2 Fljpboard 1 
Gooole Calendar 1 Gooole Drive 2 
Gooole Mail 24 


Example of applications parsed by Oxygen 


Chat applications 

Chat applications are among the most common applications on the market. These 
applications provide users with the ability to chat outside the standard SMS services offered 
by the network service provider and device and sometimes in a secure method. By secure, 
the apps may offer encryption, private profiles, private group chats, and more. 

Additionally, these apps enable the user to message others without the need for a data plan, 
as WiFi provides all the access that they need. Tango, Facebook Messenger, WhatsApp, 
Skype, and SnapChat are some of the more popular applications. 

Parsing artifacts from chat applications is not always simple. Often, multiple tools and 
methods will be required to extract all of the data. Commercial tools may only parse a 
portion of the data, forcing the examiner to learn how to examine and recover all data or 
miss evidence. Oxygen Detective is being used to parse chat messages from Tango on an 
Android device in the following screenshot. Note that the message does not show the image 
in the table. Flowever, this image can be "pieced" back into the message, as shown in the 
following screenshot, to provide the total picture of what was being shared in the 
conversation. In this example, the graphic was located and is shown with an arrow pointing 
to the message to which it belongs. This was a manual process and was not performed by 
the tool: 
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Dree... 

. Remote party 

Text 

Image URL 

Time stamp (Device ... - 

- Type 

G 

Hank Fresh 

Sweet 

N/A 

1/25/2016 4:27:52 PM 

Text 

© 

Hank Fresh 

/riara/media/O/Android/dflra/rom.s.. 

. A httD://u.tanao.net/faw... 

1/25/2016 4:27:30 PM 

Image 

© 

Hank Fresh 

1 /data/medla/O/Android/data/com.s.. 

2] <* httn://u.tanao.net/cub... 

1/25/2016 4:27:00 PM i 

^ Image 

G 

Hank Fresh 

New s4? 

N/A 

1/25/2016 4 : 26 ^ 2 ^^ 

^ Text 

© 

Hank Fresh 

Hi its fefda 

N/A 

1/25/2OJ00IR47PM 

Text 

© 

Hank Fresh 

Hello! I would like to chat with you. 

N/A 

.^if/2016 4:24:06 PM 

Text 



An example of piecing application chat logs back together 


GPS applications 

Most users branch outside their standard phone apps for GPS support. This includes getting 
directions to locations and obtaining maps for areas of interest. Common GPS applications 
include Waze, Google Maps, and more. Waze goes beyond just providing directions, as it 
also alerts the user to road hazards, traffic, and police officers that are along the path they 
are driving: 
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The Waze application 

Other applications that store location information include Twitter, Instagram, Facebook, 
Foursquare, and so on. These applications enable a user to alert friends and followers 
to their location when they create a post or share an image/video. All of these transactions 
are tracked within the app. Understanding this is key to uncovering additional artifacts that 
are not reported by your forensic tool. 

When examining location information from GPS applications, it is best to assume that you 
need to manually examine the databases and preference files that are associated with that 
application. We recommend using your forensic tool to triage the data on the device and 
then dive deeply into the artifacts, which will be discussed later in this chapter. An example 
of Waze being parsed by UFED Physical Analyzer is in the following screenshot. ITere, we 
can see that the user had five favorite locations, 74 mapped locations, and 70 recent 
directions. All of this information must be manually verified if it pertains to the 
investigation. This is due to the fact that the tool cannot determine whether the user typed 
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the address, whether it was suggested, or whether the user even traveled to that location. 
Proper skills are required by the examiner to tie a user to a specific location and this takes 
more than a forensic tool. 


•< Device Locations (513) 

PJ Journeys (16) 

- if Locations (481) 

© Apple Maps (36) 

© Facebook (1) 

© Find My iPhone (1) 

© iPhoneRecentsLog (71) 
© Mail Content (83) 

© Maps Search (4) 

© Media Locations (135) 
Reminde^^cation^l) 

© Waze F vorites (5) I 
© Waze History (74) 
^^j^az^ecent^70^ 


The Waze application in UFED physical analyzer 


Secure applications 

Secure, self-destructing, did it ever even happen? Ignore the claims of data retention and 
hunt for that data! These apps often make claims that are simply untrue. These applications 
are designed with security in mind. However, updates are released so quickly, and quality 
assurance checks seem to not be strong enough to catch everything. On occasion, you will 
find an app with an encrypted or nonexistent database, but the file has journal, write ahead 
logs, or shared memory files that contain portions of the chats that were supposed to be 
encrypted. In addition to this, the user can save media files that are shared, take screenshots 
of the conversations, and do much more. Often, you may uncover the images, audio, and 
video files that were shared and supposed to be encrypted. 

Some popular secure messaging applications include Telegram, Wickr, and Signal. Some of 
these are encrypted, and nothing is recoverable. However, this all depends on the device, 
the OS running on the smartphone, and the version of the app. The security level of these 
apps is publicly advertised, but again take this with a grain of salt. You should always 
assume that there could be a vulnerability in the app that may provide you with access 
forensically. Dig for this evidence! 
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© Information on how secure some of these apps are can be found at https : 
/ / www .eff.org/ se cure-mess aging- scorecard. 


Financial applications 

Applications that utilize financial information, such as credit card information and personal 
banking, are required to be encrypted and secure. iOS devices will not acquire these apps 
without an Apple ID and password. Even if you have the user's Apple ID and password, 
the data extracted should still be encrypted. Some examples of financial applications 
include Google Wallet, Windows Phone Wallet, PayPal, Apple Pay, and In-App Purchases. 
When you examine a device, you may see that the app was installed with the associated 
application metadata, but account information and transactions will not be accessible. 


Social networking applications 

Commercial support for social networking applications is strong as they are the most 
popular apps that are downloaded from the app stores. These applications allow users to 
make posts, share locations, chat publically, and privately and essentially catalog their life. 
Common social networking applications include Facebook, Twitter, and Instagram. Often, 
users will enable one app, such as Instagram, to have access to Facebook and Twitter so that 
posting is seamless. Thus, when examining devices, the user may find multiple copies of the 
same file or conversation due to the sharing between apps. 

When examining these apps with commercial tools, it is common for chats and contacts to 
be parsed. Other data is often overlooked. Again, this means the examiner must look at the 
data dump to ensure that nothing is missed. As an example, we are going to take a look at 
Twitter. This application stores a lot of information that may require more than one tool to 
parse. Additionally, the user may have to manually examine the database files to ensure 
that all artifacts have been recovered. 

Fet's take a look at what the tool was able to extract. As stated several times in this book, 
start with what the tool is telling you is installed, and then formulate keywords and 
methods to dig deep into the file system. We can see the user account information for 
Twitter, as well as the file path where this data is being extracted, in the following 
screenshot: 
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-*■ Application information 



Twitter 

2810 items 

com.twitter.android 


Container: /data/data/com.twitter.android 


Details: 

Source table: Accounts 
Source file: global. db 
User name: HeatherMahalik 
Name: Heather Mahalik 
User ID: M ■ ■ 

Created (Device time): 1/26/2012 8:34:14 PM 
(+00:00 UTC) 

Followers: 3002 
Followings: 454 
Favorites: 1215 
Tweets: 4037 


Twitter as parsed by Oxygen Detective 

The next logical step is to view what the tool can tell you about the application and how it 
was used. Oxygen Detective provided the following information for Twitter account usage. 
Note that both public Tweets and private messages (DM) are recovered: 


1 Categories II 

o All categories 

2810 

Accounts 

1 

El HeatherMahalk 

2794 

Users 

1508 

Folowing 

400 

Folowers 

544 

B Tweets 

199 

Folowing 

84 

Owner 

10 

Others 

105 

B Messages 

143 

B Private 

143 


5 

_Ryan» ■ 

4 

4n6wc 

4 

brian* ■ 

11 

Bryan® 

7 

Celc^ 

10 


Twitter usage by Oxygen Detective 
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After examining what was parsed by the tool, the database files should be examined to 
ensure nothing was missed. This is not always simple, as each account and function may 
have a unique database. By function, we mean that contacts may be stored in one database 
while chats and account information are stored in another. Once you become more familiar 
with common applications, you will know where to look first. At the time of writing this 
book, the following databases were the most relevant: 

• Global . db: This database contains account information, such as the username 

• <User-id> . db: This database contains notifications, messages, contacts, and 
statuses 

In the following screenshot, we can see all of the databases that are associated with Twitter. 
Again, start with what you know and dig deeper: 


File 

/data/data/com. twitter.android/cache/com. android. opengl.shaders_cache 
O /data/data/com.twitter.android/databases/O-scnbe.db 

/data/data/com.tw'itter.android/databases/O-scnbe.db-journal 
O /data/data/com.tw'itter.andro'id/databases/475222380-43.db 

/data/data/com.tw'itter.android/databases/475222380-43.db-journal 
O /data/data/com.twitter.android/databases/475222380-dm.db 

/data/data/com.twitter.android/databases/475222380-dm.db-Journal 
O /data/data/com.twitter.android/databases/475222380-drafts.db 

/data/data/com. twitter. android/databases/475222380-drafts.db-journal 
O /data/data/com.twitter.android/databases/475222380-scribe.db 

/data/data/com.twitter.android/databases/475222380-scribe.db-journal 


* /data/data/com.twitter.android/databases/gbbal.db 


/data/data/com.twitter.android/databases/gbbal.db-journal 
O /data/data/com.twitter.android/databases/persistent_jobs.db 


Twitter databases containing user activity 
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Each database may contain unique data that can be parsed for additional artifacts. These 
applications also contain unique user_id values, which can be used as keywords to search 
for other devices with traces of communication within an investigation. For this example, 
we can see user_id values, the creation date (UNIX timestamp), and the data, which is the 
result of private messaging on Twitter: 


userjd 

created 

data ( 

475222380 

1404903823000 

l-0?u? jcl wonder if the person that asked us for . . . 

29574511 

1404905109000 

I-H?' j~No, I'm with myself at E _ Blyca... 

475222380 

1404913177000 

I-s3E jaWe need test data. Not really doing resea. . . 

29574511 

1404913470000 

I-tQ??oDo you want just the chats? I can toss togeth. . . 

475222380 

1404916910000 

I-Dq? pit's not even for me. A student asked me if I h... 

29574511 

1454683850000 

I §W@??4*jHShoot me your address and I’ll try to get th. .. 


Twitter private messaging artifacts 

Custom queries can be written to parse Twitter databases of interest. A good example of 
how to do this is shown, as follows. This query is specific to parsing Twitter contacts: 

SELECT 

_id AS "Index", 
user_id, 
username, 
name, 

datetime (prof ile_created/1000 ,' UNIXEPOCH localtime 1 ) AS "Profile 
Created" , 

description AS "Twitter Description", 
web_url , 
location, 
followers , 

friends AS "Following", 

users . statuses AS "Number of Tweets", 

datetime (prof ile_created/1000 , 'UNIXEPOCH', 'localtime'), 
image_url , 

datetime (updated/1000 ,' UNIXEPOCH ',' localtime ' ) AS "Profile Updated", 
datetime (friendship_time/1000 ,' UNIXEPOCH ',' localtime ' ) AS "Became 
Friends " 

FROM users 
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Encoding versus encryption 

The terms encoding and encryption are used so frequently when discussing applications 
and smartphone data that they are often confused. Encoding is essentially the process of 
obfuscating a message or piece of information to appear as raw code. In some cases, the 
goal of encoding is to make the data unrecognizable to the computer or the user. In reality, 
the primary goal of encoding is to transform the input into a different format using a 
publicly available scheme. In other words, anyone can easily decode an encoded value. 
Encryption, however, transforms the data using a key in order to keep it secret from others. 
So, encrypted text can be reversed only if you have the key. Most applications claim that 
they encrypt the data or that the data is never saved to disk. While this is true for some, 
most are simply encoded. Encoding options can vary, but the most common for smartphone 
data is Base64. Messaging apps often rely on Base64 encoding to make the data appear to be 
hidden or "safe." A common artifact of Base64 is the padding of the data with an "=" when 
the encoded bytes are not divisible by three. 

Until a little over a year ago. Oxygen Forensics and Autopsy were two of the few tools 
supporting the decoding of Base64 payloads from applications derived from smartphones. 
For these tools to parse the data, they must support the application containing the encoding. 
Currently, MSAB, UFED Physical Analyzer, and Magnet IEF also provide Base64 decoding 
support. 

An example of Base64-encoded messages is shown in the following screenshot. This data is 
from the Tango chat application: 


conversations (3) 
( 0 ) 
( 1 ) 
( 21 ) 
(5) 
( 1 ) 
( 0 ) 


games 

likes 

messages 

profiles 

receipts 

sms 


create_time ▼ 

send_time ▼ 

payload 

1453739107566 

1453739109747 

EhZzdzlkWDIFS3Q5SkloT3hkMktrdjlRGAAiJUhlbGxvlSBJIHdvdWxkf 

1453739136466 

1453739137674 

EhZzdzlkWDILS3Q5SkloT3hkMktrdjlRGAAiFkhleSB0aGVyZSAgaXRzl 

1453739173098 

1453739173555 

EhZzdzlkWDILS3Q5SkloT3hkMktrdjlRGAAiCkhplEZIbGljaWGAAQCc 

1453739046644 

1453739053669 

EhZzTWF3Wm9laDIYRzVTd0RQMjhPYkFRGAAiJUhlbGxvlSBJIHdvdV 



Base64-encoded Tango messages 
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Encryption is a bit more difficult as the app may not even provide access to the encrypted 
data. For example, the database directory may be empty or the cells containing the 
encrypted data are simply empty. Occasionally, you will have access to the encrypted blobs 
within the databases, but this data cannot always be decrypted. Again, when you face 
encrypted data, look elsewhere. Have you examined the journal and write ahead logs? 
Have you examined the cache and media directories? Have you examined the SD card? 
These are common questions you will often have to ask yourself to ensure you are not 
relying on your forensic tools too much and that you are covering your bases to ensure 
nothing is overlooked. As explain explained, start with what you know. We know that the 
cache and database directories store user data, so this is a great place to start your manual 
examination: 


^ © com.facebook.katana (189 files, 13,447 KB) 
t> I© app_acra-reports (1 file, 1,030 KB) 

© a p p_ca I Lstats 

t> © app_gatekeepers (6 files, 65 KB) 
t> © appjight_prefs (2 files, 1 KB) 

S appjogcat 
B app_logcat_flash_logs 
B appjninidumps 
B app_omnistore (3 files, 89 KB) 

B app_qe_sessioned 
I> & app_qe_sessionless (5 files, 1 KB) 
t> B app_sessionless_gatekeepers (6 files, 1 KB) 
t~ app_state_logs (54 files, 7 KB) 

B appjraces 


arm nnlnari rra<;h monitor 


tp p 


pi 


cache (4 files, 1 KB) 


databases (16 files, 465 KB) 

dex (4 files, 1 KB) 

t> B files (5 files, 12 KB) 

B lib-assets (4 files, 1 KB) 

B lib-main (4 files, 1 KB) 
t> B lib-xzs (67 files, 11,773 KB) 
> B shared_prefs (5 files, 1 KB) 
crash Jock 
crash Jog 


r lib 


Data storage locations for applications 
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Application data storage 

Almost all applications rely on SQLite for data storage. These databases can be stored 
internally on the device or on the SD card for relevant phones. When SQLite is used, 
temporary memory files are commonly associated to each database to make SQLite more 
efficient. These files, which were previously mentioned, are write ahead logs (WAL) and 
shared memory files (SHM). These files may contain data that is not present in the SQLite 
database. Few tools will parse this information, but the ones that are offered by Sanderson 
Forensics, will get you started. Go to http : / / sandersonforensics . com/forum/conten 
t .php?261-Timelining-events-in-a-WAL-based-SQLite-DB. We can see several 
WAL and SHM files associated with various WhatsApp database files in the following 
screenshot: 


J . com.whatsapp (73 files, 2,640 KB) 
t> E? app_webview (2 files, 46 KB) 

0 E? cache (1 file, 47 KB) 

* El databases (14 files, 1,193 KB) 

!_ jobqueue-WhatsAppJobManager 
[ I jobqueue-WhatsAppJobManager-journal 
I axolotl.db 
Q) axolotl.db-shm 
L I axolotl.db-wal 
M chatsettings.db 


chatsettings.db-sh 
J chatsettings.db-wal 


3 



msgstore.db-shm 1 

L 

msqstore.db-wal | 


|_| wa.db 


ill 


wa.db-wal 


An SHM and WAL example 

In addition to SQLite databases, other devices rely on Plist, XML, JSON, and DAT files for 
application data storage, account data storage, purchase information, and user preferences. 
These files will be discussed in the Android, iOS, and Windows Phone sections. 
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iOS applications 

Apple relies on SQLite and Plists as common locations for application data storage. On 
occasion, JSON files will be used for application data. Examining applications recovered 
from an iOS device can be overwhelming. We suggest you start with what you know and 
what your tool is telling you. Examine the Installed Applications listed by your tool of 
choice. From here, go directly to the applications directory and ensure that nothing is being 
overlooked. When a user deletes an app, the databases often remain, and the link to the 
installed application is simply broken. Examining all areas of the iOS device will prevent 
the examiner from missing data: 


* _j Heather Mahalik's iPhone (5991 files, 2,536,307 KB) 

* ED Applications (1999 files, 116,475 KB) 

h 1 D 243LU875E5.groups.com.apple.podcasts (17 files, 1,07! 

t ED co.romesoft.toddlers.puzzle.shapes (3 files, 13 KB) 

t> ED com.aa.AmericanAirlines (80 files, 105 KB) 

t> ED com.airbnb.app (12 files, 666 KB) 

t> ED com.alcre8or.VideoTrimAndCut (1 file, 1 KB) 

t> ED com.allrecipes.dinnerspinner (1 file, 12 KB) 

t> ED com.amazon.Amazon (6 files, 26 KB) 

com.amazon.Amazon.watchkitextension (2 files, 2 KB) 
t> ED com.amazon.CloudDrivePhotos (14 files, 224 KB) 
t>B com.amazon.Lassen (21 files, 763 KB) 
h l D com.amtrak.rider (8 files, 147 KB) 


Installed applications on an iPhone 

After examining the installed applications, search the Library and Documents directories 
for relevant Plist files that may contain application artifacts. Finally, examine the Media 
directory on the iPhone as well as the one associated with the app to recover additional 
artifacts, such as shared photos, videos, audio files, and profile pictures, in the following 
screenshot, we are examining the Media directory associated to the WhatsApp application: 
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* E group.net.whatsapp.WhatsApp.shared (82 files, 1,169 KB) 

* E Library (1 file, 8 KB) 

I- E Preferences (1 file, 8 KB) 

* E Media (74 files, 360 KB) 

t> E Profile (74 files, 360 KB) 
t> □ Axolotl.sqlite 

ChatSearch.sqlite 
l> ChatStorage.sqlite 
_ connection.lock 
l> Lj Contacts.sqlite 
Q PPDB.plist 
LJ pw.dat 


Application data on an iPhone 


Android applications 

Android devices heavily rely on SQLite for application storage. The preference files for each 
application are often in the DAT or XML files. More so than an iOS device, examining 
application on an Android may be one of the most tedious tasks due to the various locations 
that data may be stored in. The best place to start is with a tool that will provide a listing of 
what is installed on the device. Next, go to the subdirectories off the /Root directory. 
Remember, these applications may possess unique names and may be difficult to locate. 

You may have to research the application to gain a better understanding of the filenames 
that are associated with each of them. The following screenshot is an example of application 
directories on an Android device: 
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* © data (4343 files, 1,077,324 KB) 
t> B .drm (4 files, 1,036 KB) 

t> B com.android.apps.tag (1 file, 0 KB) 
l> B com.android.backupconfirm (1 file, 0 KB) 
t> B com.android.bluetooth (1 file, 0 KB) 
l> B com.android.browser.provider (1 file, 0 KB) 
t> B com.android.calendar (7 files, 29 KB) 
d B com.android.captiveportallogin (1 file, 0 KB) 
l> B com.android.certinstaller (1 file, 0 KB) 
t> B com.android.chrome (801 files, 13,339 KB) 
t> B com.android.contacts (6 files, 1 KB) 
t> B com.android.defcontainer (1 file, 0 KB) 
l> 8 com.android.documentsui (1 file, 0 KB) 
l> 8 com.android.dreams.basic (1 file, 0 KB) 
l> B com.android.dreams.phototable r± file 0 KE-j 


Application data on an Android device 

Each of these application directories will contain a lot of data to examine. We recommend 
starting with the Databases and Cache directories and then expanding your analysis to 
other locations on the device. The next locations to examine include the Media and Cache 
partitions. If the data appears to be missing or is claimed to have been deleted, do not forget 
to examine the Downloads directory on the device and SD card. 

Application data can exist in several locations in the Media directories. Using a tool, such as 
UFED Physical Analyzer, which provides keyword-searching capabilities spanning beyond 
parsed items, will really help in locating artifacts pertaining to specific applications. We are 
looking at the large amount of data stored in the Media directory on an Android device in 
the following screenshot. This data is unique from what is stored in the application 
directory that was discussed previously. Each location needs to be thoroughly examined to 
ensure nothing is missed. It is important that you take what you learned in previous 
chapters to analyze Android application data: 
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* B media (266 files, 28,704 KB) 

B 0 (265 files, 28,704 KB) 

> I© .face (1 file, 0 KB) 
t> IB ,SPenSDK30 (1 file, 0 KB) 
B Alarms 



* B Android (212 files, 7,630 KB) 

* B data (210 files, 7,526 KB) 

l> B com.android.providers.media (1 file, 39 KB) 
t> B com.android.uending (1 file, 0 KB) 

I l> ^ com.facebook.katana | 

co^^ooglelanSSffipps.docs 
0 ^ com.google.android.apps.docs.editors.docs 


|pB conrgooglejandroidappsjTTap^^iles^3^<B^J 

0 £3 com.google.android.gms (3 files, 1 KB) 

t> © com.google.android.googlequicksearchbox (5 files, 0 KB) 

t> com.google.android.music (2 files, 1 KB) 

t> com.google.android.videos 

t> S com.google.android.youtube (1 file, 0 KB) 

t> S com.sam.apps.magazines.widget (2 files, 1 KB) 

t> S com.samsung.android.sdk.samsunglink 

t> S com.samsung.indexservice (3 files, 1 KB) 

t> S com.sec.android.app.sbrowser (9 files, 1 KB) 

l> S com.sec.android.app.shealth (2 files, 1 KB) 


its 


com.sgiggle.production (134 files, 6,040 KB) 


Unique application data in the Media directory 


Windows Phone applications 

Applications found on Windows Phones are no different than those found on iOS and 
Android devices. SQLite is the most common format used for data storage. However, not all 
devices allow for SQLite files to be stored internally on the phone. For these devices, all 
application data will be found on the SD card. Some may view this as lucky because it saves 
us from having to examine several locations on the device, but the SD card and the 
applications themselves may be encrypted. 

Where possible, it is best to remove the SD card and acquire it using a forensic tool. When 
this is not possible, the next best method would be to try to acquire the SD card through the 
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phone using a forensic tool. Again, this will often result in missed data. As a final effort, live 
analysis can be completed by mounting the device and using Windows Explorer to view the 
applications stored on the device and SD card, as discussed in Chapter 12 , Windows Phone 
Forensics. 


Forensic methods used to extract third-party 
application data 

Almost all commercial tools will attempt to support the extraction of third-party 
applications. We recommend that you test your tools thoroughly and often if you rely on 
tool output for your investigative results. This is because the apps are updated so frequently 
that it is nearly impossible for the tools to not miss something. You must learn the 
applications, how they work, and how the devices store the data for each. We strongly 
recommend that you use your tool to triage the case and then dive into the data to manually 
extract anything that the tools miss. Make sure that you only include factual data in your 
forensic report and not everything that the tools parses. The tools cannot decipher the 
difference between device and human creation. Only a trained examiner can do this with 
confidence. 


Commercial tools 

As you have seen in this book, there are many tools that can handle the job of smartphone 
forensics. However, there are a few that really shine when it comes to parsing application 
data. Magnet IEF, Oxygen Detective, Forensics Suite, and UFED Physical Analyzer are a 
few that do a good job of recovering data from the application categories discussed in this 
chapter. We will take a quick glance at how to leverage each of these tools to parse 
application data. Keep in mind that these tools will not find every application and will not 
parse all data for applications. 


Oxygen Detective 

Oxygen Detective can be used to examine application data. For this example, we are 
assuming the acquisition is complete, and we are simply attempting to analyze the data. 
Note that Oxygen is capable of acquiring and analyzing smartphones. In this example, we 
acquired the device with Cellebrite UFED and analyzed it with Oxygen. To load a data 
dump of a device and examine application artifacts, follow these steps: 
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1. Launch Oxygen Detective. 

2. Select the Import File option and choose your image. Multiple image formats are 
supported for ingestion into Oxygen. 

3. After parsing is complete, start examining the parsed applications: 


Android UFED image (blkO mmcblkO 


Sc2 Unassigned devices (1) 

4 Device Information 
Aggregated Contacts 69 
Phonebook 
a Event Log 8 
Messages 8 l 
*9 Timeline 487 l 
: File Browser 13636 
hO Passwords 2 
33 Organizer 
SI Dictionaries 
h® Links and Stats 
h Social Graph 
ho. Search 
Watch lists 
9 Key Evidence 


0B Applications 294 
EpKg) Messengers 
O Hangouts l 
Q Tango 101 
-S Zello 313 

&A Productivity (Business) 
i* Dropbox 2 
Q Flipboard 1 
3 Google Calendar l 
£» Google Drive 2 
m Google Mail 34 
$1© Social Networks 
® Google4- i 
© Pinterest 5 
Ei Twitter 2810 
1=1 Web Browsers 

| © Google Chrome 673 
O Opera Mini Web Browser 1 
Cloud Accounts 1 


The Oxygen Detective application view 

4. Next, start examining applications of interest by clicking on the application and 
examining all of the associated files. 
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5. Once you select the application, you will be presented with the data that was 
parsed and the full file path of where the data was extracted. Use this path to 
manually verify the findings. We are looking at the Pinterest application in the 
following screenshot. Note how the container, file, and table of interest 
are provided and hyperlinked for the user. The tool is even encouraging you to 
dig deeper and verify the findings: 


<*■ Application information 


■ 


Pinterest 

5 items 

mm nintoroct 


Containe^data/data/conrpinte^s^J 


Source file: pinterest.xml 


Last name: Jones 
Full name: Felicia Jones 
User name: goodb,_ 

Email: goodl ■ ■®gmail.com 
Gender: female 
User picture URL: 

http://passets-ak.pinterest.eom/images/u... 
Created (Device time): Sat, 06 Feb 2016 
22:45:55 (+00:00 UTC) 


UID: 403 


a Application information 




Pinterest 

5 items 

com.ointerest 




Details: 


Source table: BOARD 

eM4kuy«A4yji i 

Category: hair_beauty 

Secret: No 

Created (Device time): 2/6/2016 10:46:31 
PM (+00:00 UTC) 


URL: 

http://www.pinterest.com/goodbyefelicial... 
Thumbnail URL: 

http://media-cache-ec0.pinimg.com/90x9... 
Cover URL: 

https://s-media-cache-ak0.pinimg.com/20... 


UID: 4031 


Oxygen Detective Pinterest example 

Oxygen Detective has built-in features for keyword searching, bookmarking, and 
reporting. In addition, the SQLite Database and Plist Viewer will provide a 
method to examine relevant application data. 

6. Report all account information, chats, messages, locations, and any other data of 
interest as this provides relevance to your investigation. 


Magnet IEF 

Magnet IEF has been known as one of the leaders in Internet and application parsing for 
digital media. They are just as strong with mobile devices. Again, one tool cannot do the 
job, but IEF proves to be the strongest and parses the most applications from Android, iOS, 
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and Windows Phones. The downside to this tool is that we are forced to rely on the 
reported artifacts as the file system is not normalized and provided for manual 
examination. To use IEF to examine application artifacts, follow these steps: 

1. Launch IEF and then select MOBILE (note that, if MOBILE is grayed out, you 
need to obtain a license that provides mobile support from Magnet Forensics): 



Magnet IEF 

2. Select IMAGES and navigate to your image file. More than one image can be 
loaded and parsed at the same time. 

3. Select NEXT and determine what you want to parse. We recommend selecting 

CHECK ALL: 
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Dynamic App 
Finder 


Chat (18 of 18 items) 


Q a v m 'a ' 

AIM® BlackBerry Burner Google Grindr GROWLr Kik Messenger QQ® Skype® 

Messenger Hangouts 

O B - b^^a Bppi B w v mmm 0 

0 fey 4 Q □ 0 


Telegram Textfree TextMe TextPlus TigerText Tinder Viber WeChat WhatsApp 

Cloud (1 of 1 items) 


B 


Dropbox 


Documents (6 of 6 itei 

b . , y •/ 


g " ) “g 


CHECK ALL UNCHECK ALL ABOUT THE ARTIFACTS... 


Magnet IEF supported artifacts 

4. Browse to the location where you wish to save the case file and select Find 
Evidence. 

5. Once complete, the IEF Report Viewer will be displayed: 
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Recovered Artifacts Count 

A IEF Refined Results 

EB Identifiers 35 

A Chat 

O Android Telegram Chats 4 

© Android Telegram Contacts 1 

© Android Telegram Messag_ 8 

<6 Android Tinder Accounts 1 

4 Android Tinder Photos 10 


® Android WhatsApp Contacts 2 
© Android WhatsApp Messag_ 46 

A Media 

© Android WhatsApp Profile P_ 1 

A Mobile 

£. Accounts Information 5 


Application Artifacts in Magnet IEF 

The first step in examination is to review what is parsed by IEF. In the preceding 
screenshot, we can see that Telegram was parsed. Start your examination in the most 
relevant location. For example, if you are looking for Telegram chats, go right to that 
location and start examining the artifacts. Note that Messages and Chats are pulled into two 
different categories. This is common when Private Messaging is used. All relevant 
application containers should be examined. Additionally, IEF provides the full file path 
from which the data was recovered. Use another tool to navigate to this file for verification 
and manual examination. 

IEF also provides logical keyword search; essentially it will search what it can parse and 
nothing else, bookmarking and reporting. Make sure that you only report factual 
application artifacts and incorporate this into your final forensic report. 
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UFED Physical Analyzer 

Physical Analyzer is one of the most well-known mobile forensic tools on the market. This 
tool is one of the best platforms to manually conduct an examination in addition to 
leveraging the data parsed by the tool. For application analysis. Physical Analyzer is good 
at parsing chats and contacts for each supported application. For data that in not parsed. 
Physical Analyzer provides an analytical platform that enables the user to browse the file 
system to uncover additional artifacts. Keyword searching is robust in this tool and is 
capable of searching raw Flex as well as parsed data. In addition, a SQLite viewer is 
included. 

To conduct a forensic examination of application data in Physical Analyzer, follow these 
steps to get started: 

Launch Physical Analyzer by double-clicking on the UFD shortcut image file or by double- 
clicking on the tool icon. 

Load the image file and wait until parsing completes. 

Examine the parsed artifacts, as shown in the following screenshot. For this example, we are 
examining Tango. Physical Analyzer recovered Tango data in Chats, Contacts, Installed 
Applications, Passwords, and User Accounts: 


1 Analyzed Data 
t> «g| Autofill (3) 
l> OH Call Log (5) 
L Chats m 


3 


Tango (3) (19 messages) | 

Contacts (6) 

IS Google Drive (1) 

O Google Quick Search Box (1) 
Q Hangouts (1) 


L: ^ng^2^^^ 

Cookies (235) 

& Device Users (1) 

> EJ Emails (13) 

> LjJ Form Data (1) 
^^TnsTafle^^pp!!ca?!on? 


it) Powering Events (2) 
t> Searched Items (5) 

^^^^flsefflccount^W^™ 


Tango as parsed by Physical Analyzer 

We recommend examining what is parsed and referring to the hyperlink of where the data 
is being extracted. Navigate to this path and then examine the entire application directory. 
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To find the application directory, leverage built-in keyword searching capabilities to aid in 
the investigation. Remember, you may have to conduct research to determine the file names 
associated to the app if this is not apparent. Tango, for example, does not use the term 
Tango in the file paths or filenames. The directory is . sgiggle and the primary database is 
tc . db. This makes our job harder because we can't simply search for Tango and get 
accurate results. 


Open source tools 

For those on a budget, it is possible to examine application data from smartphones using 
open source solutions and cheap tools. These solutions are more difficult, and they are often 
not the answer for those new to forensics who need the assistance of a tool to aid in data 
extraction and analysis. Examining application data is tedious, and if you do not know 
where to look, the chances are that you will need to spend some money to get a head start. 
Tools, such as Andriller, can be purchased for around $500. This not free, but it's also not 
$10,000, which is what some of the other commercial tools cost. We will cover a few of our 
favorite tools that are useful in parsing application data from smartphones. 

Autopsy 

Autopsy is one of the best tools to examine Android and Windows Phones. Unfortunately, 
iOS parsing is not provided in Autopsy. Autopsy can be downloaded from http : / /sleuth 
kit . org/autopsy/. When using Autopsy, the Android Analyzer module will parse some 
application data from the device. This module is unique in that it is currently the only tool 
that parses WordsWithFriends, a gaming application, and was the first tool, other than 
Oxygen Forensics, to provide Base64 decoding support for Tango chat messages. Some say 
that Autopsy is the free solution for those who cannot afford Physical Analyzer. 

To use Autopsy, download the software and install it on a Windows machine and follow 
these instructions. Make sure that you are always using the latest version: 

1. Launch Autopsy. 

2. Create a new case: 
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Autopsy case creation 

3. Select Next and then click on Finish. 

4. Navigate to your image file and select Next. 

5. Select the modules that you wish to run. Keyword Search and Android Analyzer 
will be the most fruitful for an Android device. These modules can also be run 
after the image is ingested. The Keyword search will prove to be just as robust as 
Physical Analyzer: 
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Autopsy module selection 

6. Autopsy provides access to file system data faster than any commercial or open 
source tool available. Knowing where to go from there is the hard part. Again, 
start with anything that is in the extracted content and then dive into the file 
system and examine the files that we discussed in this book and relevant 
application data: 
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Data Sources 


S O blk0_mmcblk0.bin 

voll (Unallocated: 0-4194303) 

{ ■ vol4 (BOTAO: 8192-4202495) 

j V0l5 (BOTA1: 16384-4210687) 

±t vol6 (EFS: 24576-20996095) 

VOI7 (m9kefsl : 65536-4259839) 

| : vol8 (m9kefs2: 73728-4268031) 

!•••■■ m vol9 (m9kefs3: 81920-4276223) 
i vollO (CARRIER: 90112-4284415) 
volll (PARAM: 98304-8486911) 

VOI12 (BOOT: 114688-13746175) 

| voll3 (RECOVERY: 141312-15869951) 
voll4 (OTA: 172032-8560639) 

| voll5 (CDMA-RADIO: 188416-4382719) 
voll6 (RADIO: 196608-21168127) 

V0I17 (TOMBSTONES: 237568-4431871) 

| » voll8 (TDATA: 245760-4440063) 

St voll9 (PERSDATA: 253952-12836863) 
VOI20 (RESERVED2: 278528-4472831) 

St VOI21 (SYSTEM: 286720-2621726719) 

±1 vol22 (CACHE: 5406720-215121919) 
l+l VOI23 (HIDDEN: 5816320-58245119) 

St is VOI24 (USERDATA: 5918720-12727242751) 
vol25 (Unallocated: 30765056-37056511) 

E) • Views 
El X Results 

E Q Extracted Content 
I— Web Cookies (151) 
j : 2 Web History (10) 


Autopsy results 

Once you have identified applications of interest, start with what is parsed and then 
examine the relevant database, cache, and preference files. At the time of writing. Autopsy 
did not have a SQLite viewer available. All databases must be exported and examined in a 
SQLite viewer. We like SQLite Forensic Browser, which has been discussed in this book. 

Autopsy was able to parse Tango chat messages and contacts, similarly to Physical 
Analyzer, IEF, and Oxygen. The following screenshot shows the results of the decoded 
messages: 
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1 Table 

Thumbnail 

Source File 

Date/Time 

Direction 

Text 

Message Type 

P tc.db 

2016-01-26 16:23:06 UTC 

Outgoing 

Welcome to Tango! Remember video calls, audio c. 

. Tango Message 1 

tc.db 

2016-01-25 16:27:52 UTC 

Outgoing 

” Sweety 4} 0 Hank Fresh 

Tango Message 1 

tc.db 

2016-01-25 16:27:30 UTC 

Incoming 

* Khttp : //cget. tango . me/contentserver/down load/VqZM . 

. Tango Message 1 

^ tc.db 

2016-01-25 16:27:00 UTC 

Incoming 

* Khttp : //cget. tango . me/contentserver/down load/VqZM , 

. Tango Message 1 

^ tc.db 

2016-01-25 16:26:36 UTC 

Outgoing 

" New s4?^ 4 > 0 Hank Fresh 

Tango Message 1 

f' tc.db 

2016-01-25 16:26:24 UTC 

Outgoing 

C" ^ C^ 0 Hank Fresh 

Tango Message 1 

& tc.db 

2016-01-25 16:26:13 UTC 

Outgoing 

"Hi Felicia-^ ^ 2 Tango Member 

Tango Message 1 

P tc.db 

2016-01-25 16:25:47 UTC 

Incoming 

" Hi its felicia^ 4 > & 4 > 

4 Tango Message 1 


Tango decoded by Autopsy 


Other methods to extract application data 

One of the easiest ways to parse application data is to create custom SQLite queries and 
Python scripts to parse data of interest. We discussed several suggestions and examples of 
queries and scripts throughout this book. Python is one of the best solutions because it is 
free and we have full access to the libraries. One thing to keep in mind is that our scripts 
have to be updated frequently to keep up with application updates. Also, make sure your 
encoding schemas are correct to prevent application artifacts from being missed or not 
interpreted correctly. 

In addition to Python scripts, free parsers that support application extraction already exist. 
WhatsApp Extract is a free tool for both Android and iOS that will extract WhatsApp 
application data from devices. Often, this free tool will extract more data than the 
commercial solutions, depending on the permissions the user allocated during installation. 
Others, such as Mari DeGrazia (http : //az4n6 . blogspot . com/ p/ downloads . html) and 
Adrian Leong (https : //github . com/ cheeky4n6monkey/4n6-scripts), have 
developed scripts to parse applications, recover deleted data from SQLite free pages, 
decode Base64, and more. We recommend using what is already available before 
developing your own. 
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Summary 

Many apps are not what they claim to be. Never trust what you read about the apps, as 
Quality Assurance testing across these apps is not consistent, and we have determined 
several vulnerabilities and security flaws over the years that provide us with methods of 
piecing application data back together. In addition, application updates will change the way 
we need to look at the data. Understanding each smartphone and how it stores application 
data is the first step in successfully examining applications on smartphones. Knowing that 
updates may change data locations, encoding, and encryption, and how your tool functions, 
is one of the hardest concepts for examiners to grasp. It is your job to learn the capabilities 
of the application to uncover the most data from the mobile device. 

Understanding how an application works is hard enough, and then we have to consider 
how to extract the artifacts. As you have read in this book, there are so many ways to parse 
data from smartphones. One tool is never enough and the reality is that mobile forensics 
can be expensive. We hope that we have provided you with a practical guide that teaches 
you to acquire and analyze artifacts that are recovered from smartphones. Take what you 
learned and apply it immediately to your methods to conduct mobile forensics or use it to 
make you more prepared for your next job. Remember that practice, testing, and training 
will make you better at your job and help you perfect the art of mobile forensics. 
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